aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Remove a couple of duplicated includeMarco Costalba2007-11-05
| | | | | Signed-off-by: Marco Costalba <mcostalba@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* grep with unmerged indexJunio C Hamano2007-11-05
| | | | | | | | | We called flush_grep() every time we saw an unmerged entry in the index. If we happen to find an unmerged entry before we saw more than two paths, we incorrectly declared that the user had too many non-paths options in front. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'gp/maint-diffdoc' into maintJunio C Hamano2007-11-05
|\ | | | | | | | | * gp/maint-diffdoc: git-diff.txt: add section "output format" describing the diff formats
| * git-diff.txt: add section "output format" describing the diff formatsGerrit Pape2007-11-01
| | | | | | | | | | | | | | | | | | | | | | | | | | git-diff.txt includes diff-options.txt which for the -p option refers to a section "generating patches.." which is missing from the git-diff documentation. This patch adapts diff-format.txt to additionally mention the git-diff program, and includes diff-format.txt into git-diff.txt. Tino Keitel noticed this problem. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-daemon: fix remote port number in log entryGerrit Pape2007-11-05
| | | | | | | | | | | | | | | | The port number in struct sockaddr_in needs to be converted from network byte order to host byte order (on some architectures). Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-svn: t9114: verify merge commit message in testEric Wong2007-11-05
| | | | | | | | | | | | | | | | | | It's possible that we end up with an incorrect commit message in this test after making changes to fix the clobber bug in dcommit. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-svn: fix dcommit clobbering when committing a series of diffsEric Wong2007-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | RelNotes-1.5.3.5: fix typoDavid D Kilzer2007-11-03
| | | | | | | | | | Signed-off-by: David D Kilzer <ddkilzer@kilzer.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Delay pager setup in git blameMike Hommey2007-11-03
| | | | | | | | | | | | | | This avoids to launch the pager when git blame fails for any reason. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-cvsimport: really convert underscores in branch names to dots with -uGerrit Pape2007-11-03
| | | | | | | | | | | | | | | | | | | | | | | | The documentation states for the -u option that underscores in tag and branch names are converted to dots, but this was actually implemented for the tag names only. Kurt Roeckx reported this through http://bugs.debian.org/446495 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Fixing path quoting in git-rebaseJonathan del Strother2007-11-02
| | | | | | | | | | | | | | git-rebase used to fail when run from a path containing a space. Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | Merge branch 'bk/maint-cvsexportcommit' into maintJunio C Hamano2007-11-02
|\ \ | | | | | | | | | | | | * bk/maint-cvsexportcommit: cvsexportcommit: fix for commits that do not have parents
| * | cvsexportcommit: fix for commits that do not have parentsBrad King2007-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously commits without parents would fail to export with a message indicating that the commits had more than one parent. Instead we should use the --root option for git-diff-tree in place of a parent. Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites.Kristian Høgsberg2007-11-02
| | | | | | | | | | | | | | | | | | | | | | | | They are already set and exoprted by sourcing ./test-lib.sh in all test scripts. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Documentation: quote commit messages consistently.Sergei Organov2007-11-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Documentation quotes commit messages 14 times with double-quotes, and 7 times with single-quotes. The patch turns everything to double-quotes. A nice side effect is that documentation becomes more Windoze-friendly as AFAIK single quotes won't work there. Signed-off-by: Sergei Organov <osv@javad.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Remove escaping of '|' in manpage option sectionsJonas Fonseca2007-11-02
| |/ |/| | | | | | | | | | | The escaped were ending up verbatim in the generated documentation. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-format-patch.txt: fix explanation of an example.Sergei Organov2007-11-01
| | | | | | | | | | Signed-off-by: Sergei Organov <osv@javad.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-filter-branch.txt: fix a typo.Sergei Organov2007-11-01
| | | | | | | | | | | | Signed-off-by: Sergei Organov <osv@javad.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-clone.txt: Improve --depth description.Ralf Wildenhues2007-11-01
| | | | | | | | | | | | Avoid abbreviation 'revs', improve the language a bit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | gitweb: Update config file example for snapshot feature in gitweb/INSTALLJakub Narebski2007-11-01
|/ | | | | | | | | | Commit a3c8ab30a54c30a6a434760bedf04548425416ef by Matt McCutchen "gitweb: snapshot cleanups & support for offering multiple formats" introduced new format of $feature{'snapshot'}{'default'} value. Update "Config file example" in gitweb/INSTALL accordingly. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* GIT 1.5.3.5v1.5.3.5Junio C Hamano2007-10-31
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Update GIT 1.5.3.5 Release NotesJunio C Hamano2007-10-30
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-rebase--interactive.sh: Make 3-way merge strategies work for -p.Björn Steinbrink2007-10-30
| | | | | | | | | | | | | | | | git-rebase--interactive.sh used to pass all parents of a merge commit to git-merge, which means that we have at least 3 heads to merge: HEAD, first parent and second parent. So 3-way merge strategies like recursive wouldn't work. Fortunately, we have checked out the first parent right before the merge anyway, so that is HEAD. Therefore we can drop simply it from the list of parents, making 3-way strategies work for merge commits with only two parents. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.Björn Steinbrink2007-10-30
| | | | | | | | | | | | git-cherry-pick doesn't support a strategy paramter, so don't pass one. This means that --strategy for interactive rebases is a no-op for anything but merge commits, but that's still better than being broken. A correct fix would probably need to port the --merge behaviour from plain git-rebase.sh, but I have no clue how to integrate that cleanly. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix --strategy parsing in git-rebase--interactive.shBjörn Steinbrink2007-10-30
| | | | | | | | | For the --strategy/-s option, git-rebase--interactive.sh dropped the parameter which it was trying to parse. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make merge-recursive honor diff.renamelimitLars Hjemli2007-10-30
| | | | | | | | | | | | | | | It might be a sign of source code management gone bad, but when two branches has diverged almost beyond recognition and time has come for the branches to merge, the user is going to need all the help his tool can give him. Honoring diff.renamelimit has great potential as a painkiller in such situations. The painkiller effect could have been achieved by e.g. 'merge.renamelimit', but the flexibility gained by a separate option is questionable: our user would probably expect git to detect renames equally good when merging as when diffing (I known I did). Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cherry-pick/revert: more compact user direction messageNicolas Pitre2007-10-30
| | | | | | | | | | | | | | A failed cherry-pick (and friend) currently says: |Automatic cherry-pick failed. After resolving the conflicts, |mark the corrected paths with 'git-add <paths>' |and commit the result. This can obviously be displayed on two lines only. While at it, change "git-add" to "git add". Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* core-tutorial: Use new syntax for git-merge.Sergei Organov2007-10-30
| | | | | | | "git-merge <msg> HEAD <other branches>" is still supported but we shouldn't encourage its use. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-merge: document but discourage the historical syntaxJunio C Hamano2007-10-30
| | | | | | | | | | | | Historically "git merge" took its command line arguments in a rather strange order. Document the historical syntax, and also document clearly that it is not encouraged in new scripts. There is no reason to deprecate the historical syntax, as the current code can sanely tell which syntax the caller is using, and existing scripts by people do use the historical syntax. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Prevent send-pack from segfaulting (backport from 'master')Junio C Hamano2007-10-30
| | | | | | | | | | | | 4491e62ae932d5774f628d1bd3be663c11058a73 (Prevent send-pack from segfaulting when a branch doesn't match) is hereby cherry-picked back to 'maint'. If we can't find a source match, and we have no destination, we need to abort the match function early before we try to match the destination against the remote. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in exampleMichael W. Olson2007-10-30
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* RelNotes-1.5.3.5: describe recent fixesJunio C Hamano2007-10-29
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* merge-recursive.c: mrtree in merge() is not used before setJunio C Hamano2007-10-29
| | | | | | | | | | | | The called function merge_trees() sets its *result, to which the address of the variable mrtree in merge() function is passed, only when index_only is set. But that is Ok as the function uses the value in the variable only under index_only iteration. However, recent gcc does not realize this. Work it around by adding a fake initializer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sha1_file.c: avoid gcc signed overflow warningsJunio C Hamano2007-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | With the recent gcc, we get: sha1_file.c: In check_packed_git_: sha1_file.c:527: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false sha1_file.c:527: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false for a piece of code that tries to make sure that off_t is large enough to hold more than 2^32 offset. The test tried to make sure these do not wrap-around: /* make sure we can deal with large pack offsets */ off_t x = 0x7fffffffUL, y = 0xffffffffUL; if (x > (x + 1) || y > (y + 1)) { but gcc assumes it can do whatever optimization it wants for a signed overflow (undefined behaviour) and warns about this construct. Follow Linus's suggestion to check sizeof(off_t) instead to work around the problem. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix a small memory leak in builtin-addBenoit Sigoure2007-10-29
| | | | | | | | prune_directory and fill_directory allocated one byte per pathspec and never freed it. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* honor the http.sslVerify option in shell scriptsAurelien Bompard2007-10-28
| | | | | Signed-off-by: Aurélien Bompard <aurelien@bompard.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix generation of perl/perl.makAlex Riesen2007-10-26
| | | | | | | | | | | | | The code generating perl/Makefile from Makefile.PL was causing trouble because it didn't considered NO_PERL_MAKEMAKER and ran makemaker unconditionally, rewriting perl.mak. Makemaker is FUBAR in ActiveState Perl, and perl/Makefile has a replacement for it. Besides, a changed Git.pm is *NOT* a reason to rebuild all the perl scripts, so remove the dependency too. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-remote: fix "Use of uninitialized value in string ne"Junio C Hamano2007-10-24
| | | | | | | | | | | | | | | | martin f krafft <madduck@madduck.net> writes: > piper:~> git remote show origin > * remote origin > URL: ssh://git.madduck.net/~/git/etc/mailplate.git > Use of uninitialized value in string ne at /usr/local/stow/git/bin/git-remote line 248. This is because there might not be branch.<name>.remote defined but the code unconditionally dereferences $branch->{$name}{'REMOTE'} and compares with another string. Tested-by: Martin F Krafft <madduck@madduck.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 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>
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-03 01:21:51 +0000