aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* git-send-email: add a new sendemail.to configuration variableMiklos Vajna2007-10-24
| | | | | | | | Some projects prefer to receive patches via a given email address. In these cases, it's handy to configure that address once. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* k.org git toppage: Add link to 1.5.3 release notes.Junio C Hamano2007-10-23
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-cherry-pick: improve description of -x.Ralf Wildenhues2007-10-22
| | | | | | | | Reword the first sentence of the description of -x, in order to make it easier to read and understand. Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Correct some sizeof(size_t) != sizeof(unsigned long) typing errorsRené Scharfe2007-10-22
| | | | | | | | Fix size_t vs. unsigned long pointer mismatch warnings introduced with the addition of strbuf_detach(). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Use PRIuMAX instead of 'unsigned long long' in show-indexShawn O. Pearce2007-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Elsewhere in Git we already use PRIuMAX and cast to uintmax_t when we need to display a value that is 'very big' and we're not exactly sure what the largest display size is for this platform. This particular fix is needed so we can do the incredibly crazy temporary hack of: diff --git a/cache.h b/cache.h index e0abcd6..6637fd8 100644 --- a/cache.h +++ b/cache.h @@ -6,6 +6,7 @@ #include SHA1_HEADER #include <zlib.h> +#define long long long #if ZLIB_VERNUM < 0x1200 #define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11) allowing us to more easily look for locations where we are passing a pointer to an 8 byte value to a function that expects a 4 byte value. This can occur on some platforms where sizeof(long) == 8 and sizeof(size_t) == 4. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Merge branch 'maint'Shawn O. Pearce2007-10-21
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Describe more 1.5.3.5 fixes in release notes Fix diffcore-break total breakage Fix directory scanner to correctly ignore files without d_type Improve receive-pack error message about funny ref creation fast-import: Fix argument order to die in file_change_m git-gui: Don't display CR within console windows git-gui: Handle progress bars from newer gits git-gui: Correctly report failures from git-write-tree gitk.txt: Fix markup. send-pack: respect '+' on wildcard refspecs git-gui: accept versions containing text annotations, like 1.5.3.mingw.1 git-gui: Don't crash when starting gitk from a browser session git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs git-gui: Handle starting on mapped shares under Cygwin git-gui: Display message box when we cannot find git in $PATH git-gui: Avoid using bold text in entire gui for some fonts
| * Describe more 1.5.3.5 fixes in release notesShawn O. Pearce2007-10-21
| | | | | | | | Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * Fix diffcore-break total breakageLinus Torvalds2007-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ok, so on the kernel list, some people noticed that "git log --follow" doesn't work too well with some files in the x86 merge, because a lot of files got renamed in very special ways. In particular, there was a pattern of doing single commits with renames that looked basically like - rename "filename.h" -> "filename_64.h" - create new "filename.c" that includes "filename_32.h" or "filename_64.h" depending on whether we're 32-bit or 64-bit. which was preparatory for smushing the two trees together. Now, there's two issues here: - "filename.c" *remained*. Yes, it was a rename, but there was a new file created with the old name in the same commit. This was important, because we wanted each commit to compile properly, so that it was bisectable, so splitting the rename into one commit and the "create helper file" into another was *not* an option. So we need to break associations where the contents change too much. Fine. We have the -B flag for that. When we break things up, then the rename detection will be able to figure out whether there are better alternatives. - "git log --follow" didn't with with -B. Now, the second case was really simple: we use a different "diffopt" structure for the rename detection than the basic one (which we use for showing the diffs). So that second case is trivially fixed by a trivial one-liner that just copies the break_opt values from the "real" diffopts to the one used for rename following. So now "git log -B --follow" works fine: diff --git a/tree-diff.c b/tree-diff.c index 26bdbdd..7c261fd 100644 --- a/tree-diff.c +++ b/tree-diff.c @@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co diff_opts.detect_rename = DIFF_DETECT_RENAME; diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT; diff_opts.single_follow = opt->paths[0]; + diff_opts.break_opt = opt->break_opt; paths[0] = NULL; diff_tree_setup_paths(paths, &diff_opts); if (diff_setup_done(&diff_opts) < 0) however, the end result does *not* work. Because our diffcore-break.c logic is totally bogus! In particular: - it used to do if (base_size < MINIMUM_BREAK_SIZE) return 0; /* we do not break too small filepair */ which basically says "don't bother to break small files". But that "base_size" is the *smaller* of the two sizes, which means that if some large file was rewritten into one that just includes another file, we would look at the (small) result, and decide that it's smaller than the break size, so it cannot be worth it to break it up! Even if the other side was ten times bigger and looked *nothing* like the samell file! That's clearly bogus. I replaced "base_size" with "max_size", so that we compare the *bigger* of the filepair with the break size. - It calculated a "merge_score", which was the score needed to merge it back together if nothing else wanted it. But even if it was *so* different that we would never want to merge it back, we wouldn't consider it a break! That makes no sense. So I added if (*merge_score_p > break_score) return 1; to make it clear that if we wouldn't want to merge it at the end, it was *definitely* a break. - It compared the whole "extent of damage", counting all inserts and deletes, but it based this score on the "base_size", and generated the damage score with delta_size = src_removed + literal_added; damage_score = delta_size * MAX_SCORE / base_size; but that makes no sense either, since quite often, this will result in a number that is *bigger* than MAX_SCORE! Why? Because base_size is (again) the smaller of the two files we compare, and when you start out from a small file and add a lot (or start out from a large file and remove a lot), the base_size is going to be much smaller than the damage! Again, the fix was to replace "base_size" with "max_size", at which point the damage actually becomes a sane percentage of the whole. With these changes in place, not only does "git log -B --follow" work for the case that triggered this in the first place, ie now git log -B --follow arch/x86/kernel/vmlinux_64.lds.S actually gives reasonable results. But I also wanted to verify it in general, by doing a full-history git log --stat -B -C on my kernel tree with the old code and the new code. There's some tweaking to be done, but generally, the new code generates much better results wrt breaking up files (and then finding better rename candidates). Here's a few examples of the "--stat" output: - This: include/asm-x86/Kbuild | 2 - include/asm-x86/debugreg.h | 79 +++++++++++++++++++++++++++++++++++------ include/asm-x86/debugreg_32.h | 64 --------------------------------- include/asm-x86/debugreg_64.h | 65 --------------------------------- 4 files changed, 68 insertions(+), 142 deletions(-) Becomes: include/asm-x86/Kbuild | 2 - include/asm-x86/{debugreg_64.h => debugreg.h} | 9 +++- include/asm-x86/debugreg_32.h | 64 ------------------------- 3 files changed, 7 insertions(+), 68 deletions(-) - This: include/asm-x86/bug.h | 41 +++++++++++++++++++++++++++++++++++++++-- include/asm-x86/bug_32.h | 37 ------------------------------------- include/asm-x86/bug_64.h | 34 ---------------------------------- 3 files changed, 39 insertions(+), 73 deletions(-) Becomes include/asm-x86/{bug_64.h => bug.h} | 20 +++++++++++++----- include/asm-x86/bug_32.h | 37 ----------------------------------- 2 files changed, 14 insertions(+), 43 deletions(-) Now, in some other cases, it does actually turn a rename into a real "delete+create" pair, and then the diff is usually bigger, so truth in advertizing: it doesn't always generate a nicer diff. But for what -B was meant for, I think this is a big improvement, and I suspect those cases where it generates a bigger diff are tweakable. So I think this diff fixes a real bug, but we might still want to tweak the default values and perhaps the exact rules for when a break happens. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * Fix directory scanner to correctly ignore files without d_typeLinus Torvalds2007-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Fri, 19 Oct 2007, Todd T. Fries wrote: > If DT_UNKNOWN exists, then we have to do a stat() of some form to > find out the right type. That happened in the case of a pathname that was ignored, and we did not ask for "dir->show_ignored". That test used to be *together* with the "DTYPE(de) != DT_DIR", but splitting the two tests up means that we can do that (common) test before we even bother to calculate the real dtype. Of course, that optimization only matters for systems that don't have, or don't fill in DTYPE properly. I also clarified the real relationship between "exclude" and "dir->show_ignored". It used to do if (exclude != dir->show_ignored) { .. which wasn't exactly obvious, because it triggers for two different cases: - the path is marked excluded, but we are not interested in ignored files: ignore it - the path is *not* excluded, but we *are* interested in ignored files: ignore it unless it's a directory, in which case we might have ignored files inside the directory and need to recurse into it). so this splits them into those two cases, since the first case doesn't even care about the type. I also made a the DT_UNKNOWN case a separate helper function, and added some commentary to the cases. Linus Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * Merge branch 'maint' of git://repo.or.cz/git-gui into maintShawn O. Pearce2007-10-20
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'maint' of git://repo.or.cz/git-gui: git-gui: Don't display CR within console windows git-gui: Handle progress bars from newer gits git-gui: Correctly report failures from git-write-tree git-gui: accept versions containing text annotations, like 1.5.3.mingw.1 git-gui: Don't crash when starting gitk from a browser session git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs git-gui: Handle starting on mapped shares under Cygwin git-gui: Display message box when we cannot find git in $PATH git-gui: Avoid using bold text in entire gui for some fonts
| | * git-gui: Don't display CR within console windowsgitgui-0.8.4Shawn O. Pearce2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Git progress bars from tools like git-push and git-fetch use CR to skip back to the start of the current line and redraw it with an updated progress. We were doing this in our Tk widget but had failed to skip the CR, which Tk doesn't draw well. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: Handle progress bars from newer gitsShawn O. Pearce2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Post Git 1.5.3 a new style progress bar has been introduced that uses only one line rather than two. The formatting of the completed and total section is also slightly different so we must adjust our regexp to match. Unfortunately both styles are in active use by different versions of Git so we need to look for both. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: Correctly report failures from git-write-treeShawn O. Pearce2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | If git-write-tree fails (such as if the index file is currently locked and it wants to write to it) we were not getting the error message as $tree_id was always the empty string so we shortcut through the catch and never got the output from stderr. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: accept versions containing text annotations, like 1.5.3.mingw.1Steffen Prohaska2007-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit teaches git-gui to accept versions with annotations that start with text and optionally end with a dot followed by a number. This is needed by the current versioning scheme of msysgit, which uses versions like 1.5.3.mingw.1. However, the changes is not limited to this use case. Any version of the form <numeric version>.<anytext>.<number> would be parsed and only the starting <numeric version> used for validation. [sp: Minor edit to remove unnecessary group matching] Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: Don't crash when starting gitk from a browser sessionShawn O. Pearce2007-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the user has started git-gui from the command line as a browser we offer the gitk menu options but we didn't create the main status bar widget in the "." toplevel. Trying to access it while starting gitk just results in Tcl errors. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: Allow gitk to be started on Cygwin with native Tcl/TkShawn O. Pearce2007-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gitk expects $env(GIT_DIR) to be valid as both a path that core Git and Tcl/Tk can resolve to a valid directory, but it has no special handling for Cygwin style UNIX paths and Windows style paths. So we need to do that for gitk and ensure that only relative paths are fed to it, thus allowing both Cygwin style and UNIX style paths to be resolved. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: Ensure .git/info/exclude is honored in Cygwin workdirsShawn O. Pearce2007-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we are using Cygwin and the git repository is actually a workdir (by way of git-new-workdir) but this Tcl process is a native Tcl/Tk and not the Cygwin Tcl/Tk then we are unable to traverse the .git/info path as it is a Cygwin symlink and not a standard Windows directory. So we actually need to start a Cygwin process that can do the path translation for us and let it test for .git/info/exclude so we know if we can include that file in our git-ls-files or not. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: Handle starting on mapped shares under CygwinShawn O. Pearce2007-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I really cannot explain Cygwin's behavior here but if we start git-gui through Cygwin on a local drive it appears that Cygwin is leaving $env(PATH) in Unix style, even if it started a native (non-Cygwin) Tcl/Tk process to run git-gui. Yet starting that same git-gui and Tcl/Tk combination through Cygwin on a network share causes it to automatically convert $env(PATH) into Windows style, which broke our internal "which" implementation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: Display message box when we cannot find git in $PATHShawn O. Pearce2007-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we cannot find the git executable in the user's $PATH then we cannot function correctly. Because we need that to get the version so we can load our library correctly we cannot rely on the library function "error_popup" here, as this is all running before the library path has been configured, so error_popup is not available to us. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| | * git-gui: Avoid using bold text in entire gui for some fontsSimon Sasburg2007-09-20
| | | | | | | | | | | | Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | Improve receive-pack error message about funny ref creationJoakim Tjernlund2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | receive-pack is only executed remotely so when reporting errors, say so. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | fast-import: Fix argument order to die in file_change_mJulian Phillips2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The arguments to the "Not a blob" die call in file_change_m were transposed, so that the command was printed as the type, and the type as the command. Switch them around so that the error message comes out correctly. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | gitk.txt: Fix markup.Ralf Wildenhues2007-10-19
| | | | | | | | | | | | | | | | | | | | | For the manpage, avoid generating an em dash in code. Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | send-pack: respect '+' on wildcard refspecsJeff King2007-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When matching source and destination refs, we were failing to pull the 'force' parameter from wildcard refspecs (but not explicit ones) and attach it to the ref struct. This adds a test for explicit and wildcard refspecs; the latter fails without this patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | Improved const correctness for stringsShawn O. Pearce2007-10-21
| | | | | | | | | | | | Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | Merge git://git.kernel.org/pub/scm/gitk/gitkShawn O. Pearce2007-10-20
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/gitk/gitk: gitk: Fix "can't unset prevlines(...)" Tcl error gitk: Avoid an error when cherry-picking if HEAD has moved on gitk: Check that we are running on at least Tcl/Tk 8.4 gitk: Do not pick up file names of "copy from" lines gitk: Add support for OS X mouse wheel gitk: disable colours when calling git log
| * | | gitk: Fix "can't unset prevlines(...)" Tcl errorPaul Mackerras2007-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the error reported by Michele Ballabio, where gitk will throw a Tcl error "can't unset prevlines(...)" when displaying a commit that has a parent commit listed more than once, and the commit is the first child of that parent. The problem was basically that we had two variables, prevlines and lineends, and were relying on the invariant that prevlines($id) was set iff $id was in the lineends($r) list for some $r. But having a duplicate parent breaks that invariant since we end up with the parent listed twice in lineends. This fixes it by simplifying the logic to use only a single variable, lineend. It also rearranges things a little so that we don't try to draw the line for the duplicated parent twice. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * | | gitk: Avoid an error when cherry-picking if HEAD has moved onPaul Mackerras2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes an error reported by Adam Piątyszek: if the current HEAD is not in the graph that gitk knows about when we do a cherry-pick using gitk, then gitk hits an error when trying to update its internal representation of the topology. This avoids the error by not doing that update if the HEAD before the cherry-pick was a commit that gitk doesn't know about. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * | | gitk: Check that we are running on at least Tcl/Tk 8.4Paul Mackerras2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This checks that we have Tcl/Tk 8.4 or later, and puts up an error message in a window and quits if not. This was prompted by a patch submitted by Steffen Prohaska, but is done a bit differently (this uses package require rather than looking at [info tclversion], and uses show_error to display the error rather than printing it to stderr). Signed-off-by: Paul Mackerras <paulus@samba.org>
| * | | gitk: Do not pick up file names of "copy from" linesJohannes Sixt2007-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A file copy would be detected only if the original file was modified in the same commit. This implies that there will be a patch listed under the original file name, and we would expect that clicking the original file name in the file list warps the patch window to that file's patch. (If the original file was not modified, the copy would not be detected in the first place, the copied file would be listed as "new file", and this whole matter would not apply.) However, if the name of the copy is sorted after the original file's patch, then the logic introduced by commit d1cb298b0b (which picks up the link information from the "copy from" line) would overwrite the link information that is already present for the original file name, which was parsed earlier. Hence, this patch reverts part of said commit. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | gitk: Add support for OS X mouse wheelJonathan del Strother2007-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Väinö Järvelä supplied this patch a while ago for 1.5.2. It no longer applied cleanly, so I'm reposting it.) MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all. So i added a support for the MouseWheel event, which i limited to Tcl/tk aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to be updated from the version that is shipped with OS X 10.4 Tiger, for this patch to work. Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | gitk: disable colours when calling git logSam Vilain2007-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user specifies 'diff.color = 1' in their configuration file, then gitk will not start. Disable colours when calling git log. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | | Deduce exec_path also from calls to git with a relative pathJohannes Schindelin2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is already logic in the git wrapper to deduce the exec_path from argv[0], when the git wrapper was called with an absolute path. Extend that logic to handle relative paths as well. For example, when you call "../../hello/world/git", it will not turn "../../hello/world" into an absolute path, and use that. Initial implementation by Scott R Parish. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | | git-p4 support for perforce renames.Chris Pettitt2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current git-p4 implementation does support file renames. However, because it does not use the "p4 integrate" command, the history for the renamed file is not linked to the new file. This changeset adds support for perforce renames with the integrate command. Currently this feature is only enabled when calling git-p4 submit with the -M option. This is intended to look and behave similar to the "detect renames" feature of other git commands. The following sequence is used for renamed files: p4 integrate -Dt x x' p4 edit x' rm x' git apply p4 delete x By default, perforce will not allow an integration with a target file that has been deleted. That is, if x' in the example above is the name of a previously deleted file then perforce will fail the integrate. The -Dt option tells perforce to allow the target of integrate to be a previously deleted file. Signed-off-by: Chris Pettitt <cpettitt@gmail.com> Signed-off-by: Simon Hausmann <simon@lst.de>
* | | | git-p4: When skipping a patch as part of "git-p4 submit" make sure we ↵Simon Hausmann2007-10-20
| | | | | | | | | | | | | | | | | | | | | | | | correctly revert to the previous state of the files using "p4 revert". Signed-off-by: Simon Hausmann <simon@lst.de>
* | | | Merge branch 'maint'Shawn O. Pearce2007-10-19
|\ \ \ \ | | |/ / | |/| | | | | | | | | | * maint: Paper bag fix diff invocation in 'git stash show'
| * | | Paper bag fix diff invocation in 'git stash show'Shawn O. Pearce2007-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 89d750bf6fa025edeb31ad258cdd09a27a5c02fa I got a little too aggressive with changing "git diff" to "git diff-tree". This is shown to the user, who expects to see a full diff on their console, and will want to see the output of their custom diff drivers (if any) as the whole point of this call site is to show the diff to the end-user. Noticed by Johannes Sixt <j.sixt@viscovery.net>. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | | Merge branch 'maint'Shawn O. Pearce2007-10-19
|\ \ \ \ | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Further 1.5.3.5 fixes described in release notes Avoid invoking diff drivers during git-stash attr: fix segfault in gitattributes parsing code Define NI_MAXSERV if not defined by operating system Ensure we add directories in the correct order Avoid scary errors about tagged trees/blobs during git-fetch
| * | | Further 1.5.3.5 fixes described in release notesShawn O. Pearce2007-10-19
| | | | | | | | | | | | | | | | Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | Avoid invoking diff drivers during git-stashShawn O. Pearce2007-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git-stash needs to restrict itself to plumbing when running automated diffs as part of its operation as the user may have configured a custom diff driver that opens an interactive UI for certain/all files. Doing that during scripted actions is very unfriendly to the end-user and may cause git-stash to fail to work. Reported by Johannes Sixt Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | attr: fix segfault in gitattributes parsing codeSteffen Prohaska2007-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git may segfault if gitattributes contains an invalid entry. A test is added to t0020 that triggers the segfault. The parsing code is fixed to avoid the crash. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | Define NI_MAXSERV if not defined by operating systemPatrick Welche2007-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I found I needed NI_MAXSERV as it is defined in netdb.h, which is not included by daemon.c. Rather than including the whole header we can define a reasonable fallback value. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | Ensure we add directories in the correct orderAlex Bennee2007-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | CVS gets understandably upset if you try and add a subdirectory before it's parent directory. This patch fixes that. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | Avoid scary errors about tagged trees/blobs during git-fetchLinus Torvalds2007-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ok, what is going on is: - append_fetch_head() looks up the SHA1 for all heads (including tags): if (get_sha1(head, sha1)) return error("Not a valid object name: %s", head); - it then wants to check if it's a candidate for merging (because fetching also does the whole "list which heads to merge" in case it is going to be part of a "pull"): commit = lookup_commit_reference(sha1); if (!commit) not_for_merge = 1; - and that "lookup_commit_reference()" is just very vocal about the case where it fails. It really shouldn't be, and it shouldn't affect the actual end result, but that basically explains why you get that scary warning. In short, the warning is just bogus, and should be harmless, but I agree that it's ugly. I think the appended patch should fix it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | | Documentation/git-gc: improve description of --autoJeff King2007-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch tries to make the description of --auto a little more clear for new users, especially those referred by the "git-gc --auto" notification message. It also cleans up some grammatical errors and typos in the original description, as well as rewording for clarity. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | | Documentation/git-gc: explain --auto in descriptionJeff King2007-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that git-gc --auto tells the user to look at the man page, it makes sense to mention the auto behavior near the top (since this is likely to be most users' first exposure to git-gc). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | | git-gc: improve wording of --auto notificationJeff King2007-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous message had too much of a "boy, you should really turn off this annoying gc" flair to it. Instead, let's make sure the user understands what is happening, that they can run it themselves, and where to find more info. Suggested by Brian Gernhardt. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | | Merge branch 'jc/am-quiet'Shawn O. Pearce2007-10-18
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | * jc/am-quiet: git-am: fix typo in the previous one. git-am: make the output quieter.
| * | | | git-am: fix typo in the previous one.Junio C Hamano2007-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Caught on #git by Ulrik Sverdrup Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | git-am: make the output quieter.Junio C Hamano2007-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to say "Applying <patch subject>", "Wrote <tree object>", and "Committed <commit object>". Worse yet, with extra blank lines around them. Make the output more concise. The object names are not so useful nor interesting. Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-04 08:32:59 +0000