- 23 7月, 2009 6 次提交
-
-
由 Yann Dirson 提交于
Also mention deprecated aliases that do not appear in the send-email manpage. Signed-off-by: NYann Dirson <ydirson@altern.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
The "action" parameters for these two tests were supplied incorrectly for the way the tests were implemented. The tests check whether a program which calls hstrerror() or basename() successfully links when -lresolv or -lgen are used, respectively. A successful linking would result in NEEDS_RESOLV or NEEDS_LIBGEN being unset, and failure would result in setting the respective variable. Aside from that issue, the tests did not handle the case where neither library was necessary for accessing the functions in question. So solve both of these issues by re-working the two tests so that their form is like the NEEDS_SOCKET test which attempts to link with just the c library, and if it fails then assumes that the additional library is necessary and sets the appropriate variable. Also an entry in the config.mak.in file is necessary for the NEEDS_LIBGEN variable to appear in the config.mak.autogen file with the value assigned by the configure script. Without it, the generated shell script would contain a snippet like this: for ac_lib in ; do ... which is incorrect. Signed-off-by: NBrandon Casey <drafnel@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* maint: Trailing whitespace and no newline fix diff --cc: a lost line at the beginning of the file is shown incorrectly combine-diff.c: fix performance problem when folding common deleted lines
-
由 SZEDER Gábor 提交于
If a patch adds a new line to the end of a file and this line ends with one trailing whitespace character and has no newline, then '--whitespace=fix' currently does not remove that trailing whitespace. This patch fixes this by removing the check for trailing whitespace at the end of the line at a hardcoded offset which does not take the eventual absence of newline into account. Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
When combine-diff inspected the diff from one parent to the merge result, it misinterpreted a header in the form @@ -l,k +0,0 @@. This hunk header means that K lines were removed from the beginning of the file, so the lost lines must be queued to the sline that represents the first line of the merge result, but we incremented our pointer incorrectly and ended up queuing it to the second line, which in turn made the lossage appear _after_ the first line. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
For a deleted line in a patch with the parent we are looking at, the append_lost() function finds the same line among a run of lines that were deleted from the same location by patches from parents we previously checked. This is so that patches with two parents @@ -1,4 +1,3 @@ @@ -1,4 +1,3 @@ one one -two -two three three -quatro -fyra +four +four can be coalesced into this sequence, reusing one line that describes the removal of "two" for both parents. @@@ -1,4 -1,4 +1,3 @@@ one --two three - quatro -frya ++four While reading the second patch (that removes "two" and then "fyra"), after finding where removal of the "two" matches, we need to find existing removal of "fyra" (if exists) in the removal list, but the match has to happen after all the existing matches (in this case "two"). The code used a naïve O(n^2) algorithm to compute this by scanning the whole removal list over and over again. This patch remembers where the next scan should be started in the existing removal list to avoid this. Noticed by Linus Torvalds. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 7月, 2009 2 次提交
-
-
由 Eric Wong 提交于
Mishandling of http(s) in need of escaping was causing t9118-git-svn-funky-branch-names to fail when SVN_HTTPD_PORT was defined. This bug was exposed in (but not caused by) commit 0b2af457 (Fix branch detection when repository root is inaccessible) Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
Some unrelated tests were developed simultaneously and resulted in test numbers conflicting. To avoid difficulty when referring to tests via the "tXXXX" convention, rename the newer tests. Suggested by Marc Branchaud. Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
- 19 7月, 2009 6 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
If the message said "we will be changing the default in the future, so this is to warn people who want to keep the current default what to do", it would have made some sense, but as it stands, the message is merely an unsolicited advertisement for a new feature, which it is not helpful at all. Squelch it. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael J Gruber 提交于
'git log --no-walk' sorts commits by commit time whereas 'git show' does not (it leaves them as given on the command line). Document this by two tests so that we never forget why ba1d4505 (Tentative built-in "git show", 2006-04-15) introduced it and 8e64006e (Teach revision machinery about --no-walk, 2007-07-24) exposed it as an option argument. Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Mike Ralphson 提交于
Reorder tests introduced in fef3a7cc and 54d5cc0e so an intermittent but unimportant failure on the CVS side related to the former does not interfere with what is actually being tested. Signed-off-by: NMike Ralphson <mike@abacus.co.uk> Tested-by: NTommy Nordgren <tommy.nordgren@comhem.se> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* maint: checkout -f: deal with a D/F conflict entry correctly sha1_name.c: avoid unnecessary strbuf_release refs.c: release file descriptor on error return
-
由 Junio C Hamano 提交于
When we switch branches with "checkout -f", unpack_trees() feeds two cache_entries to oneway_merge() function in its src[] array argument. The zeroth entry comes from the current index, and the first entry represents what the merge result should be, taken from the tree recorded in the commit we are switching to. When we have a blob (either regular file or a symlink) in the index and in the work tree at path "foo", and the switched-to tree has "foo/bar", i.e. "foo" becomes a directory, src[0] is obviously that blob currently registered at "foo". Even though we do not have anything at "foo" in the switched-to tree, src[1] is _not_ NULL in this case. The unpack_trees() machinery places a special marker df_conflict_entry to signal that no blob exists at "foo", but it will become a directory that may have somthing underneath it (namely "foo/bar"), so a usual 3-way merge can notice the situation. But oneway_merge() codepath failed to notice this and passed the special marker directly to merged_entry(). This happens to remove the "foo" in the end because the df_conflict_entry does not have any name (hence the "error" message) and its addition in add_index_entry() is rejected, but it is wrong. Signed-off-by: NJunio C Hamano <gitster@pobox.com> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 7月, 2009 2 次提交
-
-
由 Brandon Casey 提交于
When we fall back to a standard for_each_reflog_ent() after failing to find the nth branch switch (or if we had a short reflog) with the call to for_each_recent_reflog_ent(), we do not need to free the memory allocated for our strbuf's since a strbuf_reset() will be performed in grab_nth_branch_switch() before assigning to the entry. Plus, the strbuf_release() negates the non-zero hint we initially gave to strbuf_init() just above these lines. Signed-off-by: NBrandon Casey <drafnel@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
Signed-off-by: NBrandon Casey <drafnel@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 7月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
This reverts commit 650d30d8. Some mailing lists are configured add prefix "[listname] " to all their messages, and also people hand-edit subject lines, be it an output from format-patch or a patch generated by some other means. We cannot stop people from mucking with the subject line, and with the change, there always will be need for hand editing the subject when that happens. People have depended on the leading [bracketed string] removal.
-
- 15 7月, 2009 3 次提交
-
-
由 Linus Torvalds 提交于
In our 'oneway_merge()' we always do an 'lstat()' to see if we might need to mark the entry for updating. But we really shouldn't need to do that when the cache entry is already marked as being ce_uptodate(), and this makes us do unnecessary lstat() calls if we have index preloading enabled. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
Not that anybody should ever get it, but somebody did (probably because of a flaky filesystem, but whatever). And each time I see an error message that I haven't seen before, I decide that next time it will look better. So this makes us write more relevant information about exactly which file ended up having issues with a missing object. Which will tell whether it was a tree object, for example, or just a regular file in the index (and which one). Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
For some reason, I ended up doing git show HEAD~5.. as an odd way of asking for a log. I realize I should just have used "git log", but at the same time it does make perfect conceptual sense. After all, you _could_ have done git show HEAD HEAD~1 HEAD~2 HEAD~3 HEAD~4 and saying "git show HEAD~5.." is pretty natural. It's not like "git show" only ever showed a single commit (or other object) before either! So conceptually, giving a commit range is a very sensible operation, even though you'd traditionally have used "git log" for that. However, doing that currently results in an error fatal: object ranges do not make sense when not walking revisions which admittedly _also_ makes perfect sense - from an internal git implementation standpoint in 'revision.c'. However, I think that asking to show a range makes sense to a user, while saying "object ranges no not make sense when not walking revisions" only makes sense to a git developer. So on the whole, of the two different "makes perfect sense" behaviors, I think I originally picked the wrong one. And quite frankly, I don't really see anybody actually _depending_ on that error case. So why not change it? So rather than error out, just turn that non-walking error case into a "silently turn on walking" instead. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 7月, 2009 3 次提交
-
-
由 SZEDER Gábor 提交于
... so it's available for git log, shortlog and gitk. Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 SZEDER Gábor 提交于
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Wincent Colaiuta 提交于
git-scm.com is now the "official" Git project page, having taken over from git.or.cz, so update the default link accordingly. This saves a redirect when people hit git.or.cz. Signed-off-by: NWincent Colaiuta <win@wincent.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 7月, 2009 3 次提交
-
-
由 Eric Wong 提交于
SVN allows uppercase A-F characters in repositories. Although `svnadmin' does not create UUIDs with uppercase by default, it is possible to change the UUID of a SVN repository and SVN itself will make no attempt to normalize them. Thanks to Esben Skovenborg for discovering this issue. Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Mattias Nissler 提交于
For the case of multiple projects sharing a single SVN repository, it is common practice to create the standard SVN directory layout within a subdirectory for each project. In such setups, access control is often used to limit what projects a given user may access. git-svn failed to detect branches (e.g. when passing --stdlayout to clone) because it relied on having access to the root directory in the repository. This patch solves this problem by making git-svn use paths relative to the given repository URL instead of the repository root. Signed-off-by: NMattias Nissler <mattias.nissler@gmx.de> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Mattias Nissler 提交于
This makes get_log more safe to use because callers cannot run into path clobbering any more. The additional overhead will not affect performance since the critical calls from the fetch loop need the path duplication anyway and the rest of the call sites is not performance critical. Signed-off-by: NMattias Nissler <mattias.nissler@gmx.de> Acked-by: NEric Wong <normalperson@yhbt.net>
-
- 11 7月, 2009 9 次提交
-
-
由 Johan Herland 提交于
quickfetch() calls rev-list to check whether the objects we are about to fetch are already present in the repo (if so, we can skip the object fetch). However, when there are many (~1000) refs to be fetched, the rev-list command line grows larger than the maximum command line size on some systems (32K in Windows). This causes rev-list to fail, making quickfetch() return non-zero, which unnecessarily triggers the transport machinery. This somehow causes fetch to fail with an exit code. By using the --stdin option to rev-list (and feeding the object list to its standard input), we prevent the overflow of the rev-list command line, which causes quickfetch(), and subsequently the overall fetch, to succeed. However, using rev-list --stdin is not entirely straightforward: rev-list terminates immediately when encountering an unknown object, which can trigger SIGPIPE if we are still writing object's to its standard input. We therefore temporarily ignore SIGPIPE so that the fetch process is not terminated. The patch also contains a testcase to verify the fix (note that before the patch, the testcase would only fail on msysGit). Signed-off-by: NJohan Herland <johan@herland.net> Improved-by: NJohannes Sixt <j6t@kdbg.org> Improved-by: NAlex Riesen <raa.lkml@gmail.com> Tested-by: NPeter Krefting <peter@softwolves.pp.se> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
Commit 003b33a8 recently added a call to basename(). On IRIX 6.5, this function resides in libgen and -lgen is required for the linker. Update configure.ac too. Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
Don't define _XOPEN_SOURCE Do define _SGI_SOURCE Defining _XOPEN_SOURCE prevents many of the common functions and macros from being defined. _Not_ setting _XOPEN_SOURCE, and instead setting _SGI_SOURCE, provides all of the XPG4, XPG5, BSD, POSIX functions and declarations, _BUT_ provides a horribly broken snprintf(). SGI does have a working snprintf(), but it is only provided when _NO_XOPEN5 evaluates to zero, and this only happens if _XOPEN_SOURCE is defined which, as mentioned above, prevents many other common functions and defines. The broken snprintf will be worked around with SNPRINTF_RETURNS_BOGUS in the Makefile in a later patch. Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
The c99 MIPSpro Compiler version 7.4.4m on IRIX 6.5 does not properly initialize run-time initialized arrays. An array which is initialized with fewer elements than the length of the array should have the unitialized elements initialized to zero. This compiler only initializes the remaining elements when the last element is a static parameter. So work around it by adding a "NULL" initialization parameter. Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* lt/dir-cleanup: Make index preloading check the whole path to the file Export thread-safe version of 'has_symlink_leading_path()' Prepare symlink caching for thread-safety Avoid using 'lstat()' to figure out directories Avoid doing extra 'lstat()'s for d_type if we have an up-to-date cache entry Simplify read_directory[_recursive]() arguments Add 'fill_directory()' helper function for directory traversal
-
由 Junio C Hamano 提交于
* ae/maint-mailinfo-rm-only-one-patch-marker: mailinfo: Remove only one set of square brackets
-
由 Junio C Hamano 提交于
For some reason there still are people who use the old style layout to put everything in $(bindir). The previous commit breaks the install for them, because it tries to unconditionally remove git from execdir and cp/ln from bindir --- oops. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 7月, 2009 4 次提交
-
-
由 Linus Torvalds 提交于
This uses the new thread-safe 'threaded_has_symlink_leading_path()' function to efficiently verify that the whole path leading up to the filename is a proper path, and does not contain symlinks. This makes 'ce_uptodate()' a much stronger guarantee: it no longer just guarantees that the 'lstat()' of the path would match, it also means that we know that people haven't played games with moving directories around and covered it up with symlinks. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
The threaded index preloading will want it, so that it can avoid locking by simply using a per-thread symlink/directory cache. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
This doesn't actually change the external interfaces, so they are still thread-unsafe, but it makes the code internally pass a pointer to a local 'struct cache_def' around, so that the core code can be made thread-safe. The threaded index preloading will want to verify that the paths leading up to a pathname are all real directories. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
If we have an up-to-date index entry for a file in that directory, we can know that the directories leading up to that file must be directories. No need to do an lstat() on the directory. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 7月, 2009 1 次提交
-
-
由 Jeff King 提交于
When a git command executes a subcommand, it uses the "git foo" form, which relies on finding "git" in the PATH. Normally this should not be a problem, since the same "git" that was used to invoke git in the first place will be found. And if somebody invokes a "git" outside of the PATH (e.g., by giving its absolute path), this case is already covered: we put that absolute path onto the front of PATH. However, if one is using "sudo", then sudo will execute the "git" from the PATH, but pass along a restricted PATH that may not contain the original "git" directory. In this case, executing a subcommand will fail. To solve this, we put the "git" wrapper itself into the execdir; this directory is prepended to the PATH when git starts, so the wrapper will always be found. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-