* Re: Bug in gitk search box
From: Junio C Hamano @ 2007-07-26 5:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Brian Downing, git
In-Reply-To: <18088.10039.780711.708582@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Junio C Hamano writes:
>
>> There was a recent message from Linus on the list, stating that
>> NUL in -z format is inter-record separator, not after-record
>> terminator.
>
> OK, I'll have to change gitk then. It looks like both Marco and I got
> tricked by this. I suggest it's worth a mention in the documentation.
I think that is indeed necessary. How about this?
---
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 8216576..228ccaf 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -43,7 +43,9 @@
Synonym for "-p --stat".
-z::
- \0 line termination on output
+ NUL-line termination on output. This affects the --raw
+ output field terminator. Also output from commands such
+ as "git-log" will be delimited with NUL between commits.
--name-only::
Show only names of changed files.
^ permalink raw reply related
* Re: [PATCH] Teach git-gui to split hunks
From: David Kastrup @ 2007-07-26 5:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0707260630570.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When you select the context menu item "Split Hunk" in the diff area,
> git-gui will now split the current hunk so that a new hunk starts at
> the current position.
>
> For this to work, apply has to be called with --unidiff-zero, since
> the new hunks can start or stop with a "-" or "+" line.
Unless one splits right at the beginning or end of an existing hunk,
wouldn't there be context which one could use? Or does it confuse
patch when adjacent hunks have overlapping contexts? At least if the
first hunk patches what is to be used as context in the second hunk, I
could imagine this. And there is really no danger of losing synch in
this situation, anyhow. So it would be more of a convenience thing
than anything else to be able to omit --unidiff-zero.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git stash apply segfaulting when called in subdir
From: Jeff King @ 2007-07-26 5:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Uwe Kleine-König, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707260635060.14781@racer.site>
On Thu, Jul 26, 2007 at 06:40:44AM +0100, Johannes Schindelin wrote:
> > The merge-recursive bug is simply a failure to check for invalid input.
>
> No it is not.
>
> The objects are there. But the objects cannot be found, since
> merge-recursive cannot go to top level.
Fair enough, I should have looked a little further. However, I still
wonder if it's better to report an error than to segfault.
-Peff
^ permalink raw reply
* Re: git stash apply segfaulting when called in subdir
From: Johannes Schindelin @ 2007-07-26 5:40 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Uwe Kleine-König, Git Mailing List
In-Reply-To: <20070726050726.GC32617@coredump.intra.peff.net>
Hi,
On Thu, 26 Jul 2007, Jeff King wrote:
> On Wed, Jul 25, 2007 at 03:28:12PM -0700, Junio C Hamano wrote:
>
> > > zeisberg@cassiopeia:/tmp/repo$ cd dir; git stash apply
> > > error: missing object referenced by '696146c2a44d7fc4d5ae4a71589c4c0d84f59789'
> > > /home/zeisberg/usr/bin/git-stash: line 111: 13618 Segmentation fault git-merge-recursive $b_tree -- $c_tree $w_tree
> >
> > This probably is a merge-recursive bug, but in the meantime,
> > I think this should fix it.
>
> The merge-recursive bug is simply a failure to check for invalid input.
No it is not.
The objects are there. But the objects cannot be found, since
merge-recursive cannot go to top level.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Teach git-gui to split hunks
From: Johannes Schindelin @ 2007-07-26 5:32 UTC (permalink / raw)
To: Shawn O. Pearce, git
When you select the context menu item "Split Hunk" in the diff area,
git-gui will now split the current hunk so that a new hunk starts at
the current position.
For this to work, apply has to be called with --unidiff-zero, since
the new hunks can start or stop with a "-" or "+" line.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
No more complaining from me about the lack of that feature.
And I did not even need a C compiler to do that.
git-gui.sh | 4 +++
lib/diff.tcl | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 78 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index a38293a..a0f7617 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2400,6 +2400,10 @@ $ctxm add command \
-command {apply_hunk $cursorX $cursorY}
set ui_diff_applyhunk [$ctxm index last]
lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]
+$ctxm add command \
+ -label [mc "Split Hunk"] \
+ -command {split_hunk $cursorX $cursorY}
+lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
$ctxm add separator
$ctxm add command \
-label {Decrease Font Size} \
diff --git a/lib/diff.tcl b/lib/diff.tcl
index e09e125..88ec8f3 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -265,6 +265,79 @@ proc read_diff {fd} {
}
}
+proc split_hunk {x y} {
+ global current_diff_path current_diff_header current_diff_side
+ global ui_diff ui_index file_states
+
+ if {$current_diff_path eq {} || $current_diff_header eq {}} return
+ if {![lock_index apply_hunk]} return
+
+ set c_lno [lindex [split [$ui_diff index @$x,$y] .] 0]
+ set s_idx [$ui_diff search -backwards -regexp ^@@ $c_lno.0 0.0]
+ if {$s_idx eq {} || $s_idx >= [expr $c_lno - 1]} {
+ unlock_index
+ return
+ }
+ set s_lno [lindex [split $s_idx .] 0]
+
+ # the first hunk will look like this: @@ -$m1,$m2 +$p1,$p2 @@
+ # the second hunk will look like this: @@ -$m3,$m4 +$p3,$p4 @@
+
+ # get original hunk numbers
+ set hunk_line [$ui_diff get $s_idx "$s_idx lineend"]
+ set re "@@ +-(\[0-9\]+)(,(\[0-9\]+))? +\\+(\[0-9\]+)(,(\[0-9\]+))? *@@"
+ if {![regexp $re $hunk_line dummy m1 dummy m4 p1 dummy p4] ||
+ $m1 == 0 || $p1 == 0} { # create/delete file
+ unlock_index
+ return
+ }
+ if {$m4 == ""} {
+ set m4 1
+ }
+ if {$p4 == ""} {
+ set p4 1
+ }
+
+ # count changes
+ set m2 0
+ set p2 0
+ for {set l [expr $s_lno + 1]} {$l < $c_lno} {incr l} {
+ switch -exact -- [$ui_diff get $l.0] {
+ " " {
+ incr m2
+ incr p2
+ }
+ "+" {
+ incr p2
+ }
+ "-" {
+ incr m2
+ }
+ }
+ }
+
+ # We could check if {$m2 == $p2 && $m2 == [expr $c_lno - $s_lno]}
+ # and just remove the hunk. But let's not be too clever here.
+
+ set m3 [expr $m1 + $m2]
+ set m4 [expr $m4 - $m2]
+ set p3 [expr $p1 + $p2]
+ set p4 [expr $p4 - $p2]
+
+ if {$m4 == 0 && $p4 == 0} {
+ index_unlock
+ return
+ }
+
+ $ui_diff configure -state normal
+ $ui_diff delete $s_idx "$s_idx lineend"
+ $ui_diff insert $s_idx "@@ -$m1,$m2 +$p1,$p2 @@" d_@
+ $ui_diff insert $c_lno.0 "@@ -$m3,$m4 +$p3,$p4 @@\n" d_@
+ $ui_diff configure -state disabled
+
+ unlock_index
+}
+
proc apply_hunk {x y} {
global current_diff_path current_diff_header current_diff_side
global ui_diff ui_index file_states
@@ -272,7 +345,7 @@ proc apply_hunk {x y} {
if {$current_diff_path eq {} || $current_diff_header eq {}} return
if {![lock_index apply_hunk]} return
- set apply_cmd {apply --cached --whitespace=nowarn}
+ set apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}
set mi [lindex $file_states($current_diff_path) 0]
if {$current_diff_side eq $ui_index} {
set mode unstage
--
1.5.3.rc2.42.gda8d-dirty
^ permalink raw reply related
* Re: Windows support
From: Johannes Schindelin @ 2007-07-26 5:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dmitry Kakurin, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20070726040003.GR32566@spearce.org>
Hi,
On Thu, 26 Jul 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 25 Jul 2007, Dmitry Kakurin wrote:
> >
> > > On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > > > What features is mingw port missing?
> > > Well, 'git commit' from a regular cmd prompt does not work.
> > > IMHO, That's a pretty serious omission :-).
> >
> > Not true.
>
> Use git-gui. ;-) It doesn't need a shell to make commits.
Of course. Ever since I saw git-gui, I was convinced that _this_ is the
tool Windows users should use.
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-26 5:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Dmitry Kakurin, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7v6447bxc1.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 25 Jul 2007, Junio C Hamano wrote:
> If that is the case, "Git for Windows" probably should package MSYS as
> part of it, I would think, to match the expectation of the users there.
> I know two Johannes'es and Han-Wen spent quite a lot of effort on
> Windows port and packaging, but perhaps that little (well, I should not
> be judging if that is a little or huge, as I do not do Windows)
> finishing touch would make Windows users much happier?
Windows users are only happy when they can bug developers.
Seriously again, the biggest problem with Han-Wen's installer was that it
insists on cross-compiling _all_ the packages. This makes it easy for
Han-Wen to upgrade packages and compile the thing on Linux in one go.
However, it never worked with bash, and I could not fix it: I can read
Python, but not _that_ Python.
So my plan was to wrap everything needed from an existing MinGW/MSYS
installation, with a minimal installer (NullSoft or whatever) to setup the
exec dir, perl lib path etc...
However, my time is scarce, and it does not exactly help that all I can
expect from those who should be thankful is even more complaining.
I mean, I understand Linus' point. I don't even expect a Windows user to
compile C. It's long time since I was silly enough to believe that. But
just wrapping it up in an installer, and a little testing, seems to be too
much to ask. When I don't need the darned thing to begin with.
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Steven Grimm @ 2007-07-26 5:11 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707251956h3db847c9v8db438f4c665b2cf@mail.gmail.com>
Wrote this reply privately earlier; forwarding to the list at Dmitry's
suggestion (though it's rendered slightly less relevant by his
clarifications)...
Dmitry Kakurin wrote:
> This actually answers my question (if it's true).
> If core team is not interested in supporting Windows then I cannot
> trust this system with my source code :-(.
>
I certainly understand the conclusion, but I'm not sure I would share
it. Unless you have reason to believe there's something in particular
about the Windows environment that would cause git to lose data in
circumstances where it wouldn't do so under UNIX-ish systems, it seems
like your data should be perfectly safe.
In the year-and-a-bit I've been lurking on the git mailing list and
making occasional contributions to the code, git has never lost any data
for anyone to my knowledge. Its design is extremely paranoid in that
regard, and the paranoia is not really anything platform-dependent. It's
stuff like, never overwrite files in place (always write a new file
then, once it's written successfully, get rid of the old one if needed).
Or, as importantly, keep SHA1 hashes of *everything* and double-check
them often. Those approaches are just as valid on Windows as on any
other OS. The SHA1 hashes in particular are pretty unimpeachable, IMO;
the times people have thought their git repositories have gotten
corrupted, it has always turned out to be underlying filesystem or disk
corruption that git's SHA1 checking has caught.
If there are data loss bugs in git (and of course it's possible, even if
none have been reported to my knowledge) IMO they're vastly more likely
to be generic than platform-specific.
One nice thing about git is you don't have to take its word for your
data integrity. You can, without a whole lot of effort, dump out every
file in the repository and verify that it is what git says it is.
Anyway, I guess my feeling would be, if I were going to choose to not
use git on Windows it would be because of smoothness of the experience,
lack of integration with Windows tools, difficult installation process,
or stuff like that. Data integrity would not even cross my mind as a
downside of git.
-Steve
^ permalink raw reply
* Re: git stash apply segfaulting when called in subdir
From: Jeff King @ 2007-07-26 5:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, Git Mailing List
In-Reply-To: <7v1wewdsoz.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 25, 2007 at 03:28:12PM -0700, Junio C Hamano wrote:
> > zeisberg@cassiopeia:/tmp/repo$ cd dir; git stash apply
> > error: missing object referenced by '696146c2a44d7fc4d5ae4a71589c4c0d84f59789'
> > /home/zeisberg/usr/bin/git-stash: line 111: 13618 Segmentation fault git-merge-recursive $b_tree -- $c_tree $w_tree
>
> This probably is a merge-recursive bug, but in the meantime,
> I think this should fix it.
The merge-recursive bug is simply a failure to check for invalid input.
Patch to at least print and die rather than segfault is below.
Technically the error could be from a tag dereference, too, so maybe the
error message should be more exact?
-- >8 --
merge-recursive: don't segfault on missing input objects
This should generally never happen, but it's nicer to report
an error than to segfault.
Signed-off-by: Jeff King <peff@peff.net>
---
merge-recursive.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index c8539ec..2764e61 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1692,6 +1692,8 @@ static struct commit *get_ref(const char *ref)
if (get_sha1(ref, sha1))
die("Could not resolve ref '%s'", ref);
object = deref_tag(parse_object(sha1), ref, strlen(ref));
+ if (!object)
+ die("Object does not exist: %s", ref);
if (object->type == OBJ_TREE)
return make_virtual_commit((struct tree*)object,
better_branch_name(ref));
--
1.5.3.rc3.818.gc1dc7-dirty
^ permalink raw reply related
* Re: Bug in gitk search box
From: Paul Mackerras @ 2007-07-26 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, git
In-Reply-To: <7vtzrrc1sb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> There was a recent message from Linus on the list, stating that
> NUL in -z format is inter-record separator, not after-record
> terminator.
OK, I'll have to change gitk then. It looks like both Marco and I got
tricked by this. I suggest it's worth a mention in the documentation.
Paul.
^ permalink raw reply
* Re: Git User's Survey 2007
From: Steven Grimm @ 2007-07-26 4:52 UTC (permalink / raw)
To: Marco Costalba; +Cc: Jakub Narebski, git
In-Reply-To: <e5bfff550707250919s57ba2ecar2f5ddfd923c8a833@mail.gmail.com>
Marco Costalba wrote:
> I think the next step will be to raise some funds to make Johannes
> work out the Windows port :-)
I was thinking the same thing when I read his reply. I'm not a Windows
user, but I'd pitch in a bit of cash for that in the interest of
spreading git around more widely. (Deferred self-interest: making git
popular with Windows users will probably result in new features I'll
want too.) Not enough to fund the whole thing -- I'm talking
out-of-pocket here -- but if other people did the same we could probably
come up with a respectable sum.
Though obviously the best case would be for some company to decide it
wants the work done and make an actual business arrangement for it.
-Steve
^ permalink raw reply
* Re: Windows support
From: Junio C Hamano @ 2007-07-26 4:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dmitry Kakurin, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20070726031838.GO32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I do know the best way to uninstall dependencies on Windows is to
> boot a live Linux CD and `mkfs /dev/hda1`. But as far as installing
> things go you pray that your vendor has packaged everything you need
> in their shiny click-through installer thing, and if they haven't,
> you cry wolf and switch to another vendor.
If that is the case, "Git for Windows" probably should package
MSYS as part of it, I would think, to match the expectation of
the users there. I know two Johannes'es and Han-Wen spent quite
a lot of effort on Windows port and packaging, but perhaps that
little (well, I should not be judging if that is a little or
huge, as I do not do Windows) finishing touch would make Windows
users much happier?
^ permalink raw reply
* Re: [PATCH] Fix git_mkstemp to return an error when path is too long.
From: Junio C Hamano @ 2007-07-26 4:26 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Johannes Schindelin
In-Reply-To: <46A7F9C4.7030004@gmail.com>
Carlos Rica <jasampler@gmail.com> writes:
> Now the function returns -2 to the caller if the given buffer
> is too short to save the entire path for the temporary file.
>
> Signed-off-by: Carlos Rica <jasampler@gmail.com>
Trying not to overstep the static buffer is of course a good
thing, and I think it is probably Ok to error out on a TMPDIR
environment variable that is insanely long, instead of using an
extra malloc/free, as underlying mkstemp() would error out if it
is given an insanely long template buffer anyway.
However, I think it is not so useful to return -2, even if that
is done so that you can differentiate the case where the TMPDIR
and/or the template were too long and the case mkstemp() errored
out.
Stop and think for a minute: what does the underlying mkstemp()
do, if the given template is too long?
That's right. You would get ENAMETOOLONG. So why don't we do
this instead?
---
diff.c | 2 +-
path.c | 25 ++++++++++---------------
2 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/diff.c b/diff.c
index cd6b0c4..a5fc56b 100644
--- a/diff.c
+++ b/diff.c
@@ -1695,7 +1695,7 @@ static void prep_temp_blob(struct diff_tempfile *temp,
fd = git_mkstemp(temp->tmp_path, PATH_MAX, ".diff_XXXXXX");
if (fd < 0)
- die("unable to create temp-file");
+ die("unable to create temp-file: %s", strerror(errno));
if (write_in_full(fd, blob, size) != size)
die("unable to write temp-file");
close(fd);
diff --git a/path.c b/path.c
index c4ce962..dc7ded9 100644
--- a/path.c
+++ b/path.c
@@ -71,25 +71,20 @@ char *git_path(const char *fmt, ...)
/* git_mkstemp() - create tmp file honoring TMPDIR variable */
int git_mkstemp(char *path, size_t len, const char *template)
{
- char *env, *pch = path;
-
- if ((env = getenv("TMPDIR")) == NULL) {
- strcpy(pch, "/tmp/");
- len -= 5;
- pch += 5;
- } else {
- size_t n = snprintf(pch, len, "%s/", env);
-
- len -= n;
- pch += n;
+ const char *tmp;
+ size_t n;
+
+ tmp = getenv("TMPDIR");
+ if (!tmp)
+ tmp = "/tmp";
+ n = snprintf(path, len, "%s/%s", tmp, template);
+ if (len <= n) {
+ errno = ENAMETOOLONG;
+ return -1;
}
-
- strlcpy(pch, template, len);
-
return mkstemp(path);
}
-
int validate_headref(const char *path)
{
struct stat st;
^ permalink raw reply related
* Re: Windows support
From: Shawn O. Pearce @ 2007-07-26 4:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, Nguyen Thai Ngoc Duy, git
In-Reply-To: <Pine.LNX.4.64.0707260438210.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 25 Jul 2007, Dmitry Kakurin wrote:
>
> > On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > > What features is mingw port missing?
> > Well, 'git commit' from a regular cmd prompt does not work.
> > IMHO, That's a pretty serious omission :-).
>
> Not true.
Use git-gui. ;-) It doesn't need a shell to make commits.
It currently uses the shell for fetch and for merge. I'm fixing
merge this week. I'm hoping Daniel's native C fetch will fix
the fetch.
--
Shawn.
^ permalink raw reply
* Re: Windows support
From: Dmitry Kakurin @ 2007-07-26 3:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <Pine.LNX.4.64.0707260438210.14781@racer.site>
On 7/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > > What features is mingw port missing?
> > Well, 'git commit' from a regular cmd prompt does not work.
> > IMHO, That's a pretty serious omission :-).
> Not true.
Well, repro is very simple:
* Follow instructions on Git Wiki and install Git from
http://lilypond.org/git/binaries/mingw/
* run git commit:
E:\Git\usr\bin>git commit
git: 'commit' is not a git-command
I've tried on both Win XP and Vista machines.
- Dmitry
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-26 3:38 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <a1bbc6950707251926t11e1d0f7p8e8cd8c936f7ff72@mail.gmail.com>
Hi,
On Wed, 25 Jul 2007, Dmitry Kakurin wrote:
> On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > What features is mingw port missing?
> Well, 'git commit' from a regular cmd prompt does not work.
> IMHO, That's a pretty serious omission :-).
Not true.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix git_mkstemp to return an error when path is too long.
From: Johannes Schindelin @ 2007-07-26 3:36 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Junio C Hamano
In-Reply-To: <46A7F9C4.7030004@gmail.com>
Hi,
On Thu, 26 Jul 2007, Carlos Rica wrote:
> @@ -79,12 +80,14 @@ int git_mkstemp(char *path, size_t len, const char *template)
> pch += 5;
> } else {
> size_t n = snprintf(pch, len, "%s/", env);
> -
> + if (n >= len)
> + return -2;
That is certainly a bug fixed (even if few people have an insanely long
TMPDIR...)
> len -= n;
> pch += n;
> }
>
> - strlcpy(pch, template, len);
> + if (strlcpy(pch, template, len) >= len)
> + return -2;
Maybe just "return error("filename too long: %.*s", 60, pch);"? So that
all callers to git_mkstemp() get the message for free?
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Shawn O. Pearce @ 2007-07-26 3:36 UTC (permalink / raw)
To: Stephen Cuppett; +Cc: Steffen Prohaska, git
In-Reply-To: <316a20a40707250958w1fe9f6fdn41d75ca704aeb9cd@mail.gmail.com>
Stephen Cuppett <cuppett@gmail.com> wrote:
> On 7/25/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> >Is it just that windows developer hate cygwin because it's to
> >complex to install or is there any severe limitation?
> >functionality? stability? performance?
>
> I actually have no problems with cygwin and find it works pretty well
> with git repositories. Starting the xserver to run git-gui is pretty
> annoying though.
I've never even tried to run it that way. I know the Cygwin packages
have two different Tcl/Tk binaries: one that is actually a hacked
up native Tcl/Tk (which uses native Win32 graphics) and one that
is a straightup recompile of the UNIX Tcl/Tk (which uses X11 only).
I only have the native Win32 Tcl/Tk installed, and thus run native
graphics.
An advantage of the native Tcl/Tk is just that, its native.
A downside is it is native. It doesn't use the Cygwin APIs for exec,
it directly goes through CreateProcess(). It doesn't use the Cygwin
APIs for file IO, it goes directly through the native Win32 stuff.
Which means it sometimes has a difficult time with Cygwin paths.
There are a few places in git-gui where I run `cygpath -w` just to
handle this.
I've also recently tested git-gui under the ActiveState Tcl
distribution. It ran, but for reasons unknown to me (I didn't
research it yet) the .git/info/exclude rules didn't apply when
git-gui spawned a `git ls-files --others` helper process.
I have considered doing a starkit of git-gui, msys based git
executables/dlls, and the ActiveState Tcl engine. That should give
users a single git-gui.exe that they can just download and launch,
no installation required. Haven't started it yet, partly because
I haven't finished removing the need for shell scripts to support
git-gui. I'm almost there, especially with Daniel Barkalow's work
on a native C fetch.
> Windows-based development teams are going to expect
> easy access to those kinds of tooling. Otherwise, the champion will
> be pushing a type of workflow change that would hinder adoption anyway
> and leave a sour taste for a long time.
I agree. They also want this thing called "explorer integration" or
something like that. I've never had good luck with cra^H^H^Hpackages
that install themselves into the Windows explorer UI. I would
probably never develop such a thing myself.
> I don't know if the performance problems are cygwin or not. More
> knowledgeable people might be able to answer, it's just what I'm
> observing right now. It could be more fundamental to the types of
> access being performed en masse on inode-based versus NTFS systems.
As Linus described its NTFS/Windows that is horrid here, and not
really Cygwin. Linux is just fast. Almost all modern UNIXes are.
At least when compared to the Windows kernel running on a crappy
4500 RPM IDE drive that is also hampered with a virus scanner that
wants to scan 12 GiB of data every 30 minutes, even when the volume
has only 8 GiB of files on it. ;-)
Git is fast. Its faster than SVN on the same hardware. Even under
Windows. About the only thing that I think is "slow" is two areas:
* status. Doing lstat() on 8,000+ files takes a little while.
Hooking into the OS' native file monitoring facility and having
that tell us which files are stat-dirty would reduce the need
for these massive lstat() runs.
* for-each-ref. Opening 400 ref files to read their current SHA-1
values is not fast on Windows. More aggressively packing refs
(at least on Windows) may actually be worthwhile. Another option
might be to have the same process that is watching the OS' file
monitoring interface cache the ref values, so we can get to them
via say shared memory or a pipe instead of file IO.
Neither feature is really necessary on a good UNIX however, as most
kernel development teams have just made sure their system has good
file IO throughput. Oh, and they don't have to run virus scanners
that get higher IO priority than everything else.
--
Shawn.
^ permalink raw reply
* Re: [Bradford C. Smith] [PATCH 2/2] use lockfile.c routines in git_commit_set_multivar()
From: Johannes Schindelin @ 2007-07-26 3:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ioocatt.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 25 Jul 2007, Junio C Hamano wrote:
> From: "Bradford C. Smith" <bradford.carl.smith@gmail.com>
> Subject: [PATCH 2/2] use lockfile.c routines in git_commit_set_multivar()
> Date: Wed, 25 Jul 2007 12:49:53 -0400
> Message-Id: <11853821962210-git-send-email-bradford.carl.smith@gmail.com>
>
> Changed git_commit_set_multivar() to use the routines provided by
> lockfile.c to reduce code duplication and ensure consistent behavior.
>
> Signed-off-by: "Bradford C. Smith" <bradford.carl.smith@gmail.com>
>
> Dscho, I think this is worth doing regardless of that "symlinked
> config" issue. I haven't followed the code closely enough,
> though.
>
> What do you think?
I think that I will review it tomorrow; this darned work-tree stuff took
way longer than expected.
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Shawn O. Pearce @ 2007-07-26 3:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Kakurin, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vps2fc196.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> "Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
>
> > On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> >> What features is mingw port missing?
> > Well, 'git commit' from a regular cmd prompt does not work.
> > IMHO, That's a pretty serious omission :-).
>
> I was under the impression that is only because you do not have
> MSYS installed. Doesn't Windows people have automated way to
> pull and install other packages on the dependency?
Package management? On Windows? Surely you aren't talking about
that silly "Add/Remove Programs" control panel that just destroys
your machine.
I do know the best way to uninstall dependencies on Windows is to
boot a live Linux CD and `mkfs /dev/hda1`. But as far as installing
things go you pray that your vendor has packaged everything you need
in their shiny click-through installer thing, and if they haven't,
you cry wolf and switch to another vendor.
--
Shawn.
^ permalink raw reply
* Re: Windows support
From: Shawn O. Pearce @ 2007-07-26 3:15 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Steven Grimm, git
In-Reply-To: <a1bbc6950707251956h3db847c9v8db438f4c665b2cf@mail.gmail.com>
Dmitry Kakurin <dmitry.kakurin@gmail.com> wrote:
> On 7/25/07, Steven Grimm <koreth@midwinter.com> wrote:
> > > How serious are you guys about Windows support?
> > Much (nearly all?) of the core git team never touches Windows, so they
> > both have no selfish motivation to get it working well and no way to
> > test their changes even if they decide to take it up for the greater good.
>
> This actually answers my question (if it's true).
> If core team is not interested in supporting Windows then I cannot
> trust this system with my source code :-(.
It more or less is. Those of us that are most active as Git
developers don't really use Windows as our core development platform.
Well, that is not entirely true. Day-job forces Windows on me,
because its the Most Secure Operating System Evar!. :-) I run Cygwin
there so I have a sane user interface, and build Git under Cygwin
rather than MSYS because I just expect the UNIX-like environment
that Cygwin gives me.
Why Cygwin? Because I have to use Windows, but I'd rather use Linux.
No, Linux isn't permitted. And Solaris/x86 is only allowed on
"servers". I have yet to find a way to classify my desktop as
a server. :-|
git-gui is fairly well supported under Cygwin, as I use it a lot
in my day-job. As do a lot of my coworkers. Which actually gives
me a pretty good testing ground; ~20 people all beating on git-gui
all day long is a pretty sizable testing group. I actually wonder
some days if git-gui is better tested on Cygwin than it is on Linux.
But as has been stated on this thread, Cygwin isn't native Windows.
> My concerns are (mostly):
> * lack of (or insufficient) testing for Windows platform
> * possibly lower code quality of Windows port, since core devs don't
> touch it and don't care
We do care. Its just not our primary focus. Dscho, Junio, Daniel
Barkalow, Johannes Sixt, myself, even Linus have all contributed
patches to git that help make it run better on Windows, or make
it easier to port there. But none of us are running out and
dedicating our lives to making Git the best software to ever run
on that platform. There's other things more important to us.
> * possible troubles with support if issues arise
> * Windows port could become abandoned if those few brave people, who
> work on it right now will leave
That's always a concern. Heck, day-job invested untold fortunes in
a product we purchased from a large commerical vendor. Runs only on
Windows. Vendor just up and decided to no longer support the product
anymore and has left us hanging out to dry. Did I mention that the
product is also closed source and less stable than Git is on Windows?
So no matter what you use, if the developers leave, you are stuck.
But one thing I *really* love about Git is how simple the data
structures are and how easy it is to read the repository. Its under
500 lines of C code to unpack a working directory. More if you
want something that's blazing fast and always reliable, but if you
just want to get the data out its quite simple.
Its also fully open source. GPL'd even. So there's never the
issue that your vendor runs away and prevents you from taking on
development yourself, or just fixing those minor issues that you
really need to have fixed.
--
Shawn.
^ permalink raw reply
* [PATCH] git-write-tree should not crash if prefix does not exist
From: Nguyễn Thái Ngọc Duy @ 2007-07-26 3:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, pclouds
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Resend as it seems git-send-email and vger.kernel.org don't like me
much
builtin-write-tree.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-write-tree.c b/builtin-write-tree.c
index 391de53..88f34ba 100644
--- a/builtin-write-tree.c
+++ b/builtin-write-tree.c
@@ -52,6 +52,8 @@ int write_tree(unsigned char *sha1, int missing_ok, const char *prefix)
if (prefix) {
struct cache_tree *subtree =
cache_tree_find(active_cache_tree, prefix);
+ if (!subtree)
+ die("git-write-tree: prefix %s not found", prefix);
hashcpy(sha1, subtree->sha1);
}
else
--
1.5.2
^ permalink raw reply related
* Re: problem after cvsimport
From: Junio C Hamano @ 2007-07-26 3:07 UTC (permalink / raw)
To: Bert Douglas; +Cc: git
In-Reply-To: <46A7FD99.9000305@tplogic.com>
Bert Douglas <bertd@tplogic.com> writes:
> I am new to git, so probably doing something wrong.
> Hope somebody can enlighten me.
> Here is what happened so far.
>
> Followed instructions here:
> http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
>
> Did command like this:
>
> $ git cvsimport -C <destination> <module>
>
> This was done from top level of existing cvs working directory.
> Destination was new empty directory, outside the cvs tree.
>
> It worked for several hours and seemed to complete ok.
> I can look at history in destination git directory with gitk and git log.
> All the stuff in ".git" looks normal, as far as I can tell.
>
> But I have no files in the working directory.
> When I do command:
> $git checkout master
>
> I get a bunch of lines to console with "D" in front.
> Btw, what does that mean? Nothing about it in "man git-checkout" or elsewhere that I can find.
> Then it says -- Already on branch "master"
>
> But working directory is still empty.
Have you tried "git checkout -f" after that? With recent enough
git, "git cvsimport -C <destination> <module>" from the top
level of existing cvs working directory, with nonexistent
destination directory (that is, you let "git cvsimport -C" to
create that destination directory) would run "git checkout -f"
for you.
^ permalink raw reply
* Re: Windows support
From: Junio C Hamano @ 2007-07-26 3:06 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <a1bbc6950707251926t11e1d0f7p8e8cd8c936f7ff72@mail.gmail.com>
"Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
> On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> What features is mingw port missing?
> Well, 'git commit' from a regular cmd prompt does not work.
> IMHO, That's a pretty serious omission :-).
I was under the impression that is only because you do not have
MSYS installed. Doesn't Windows people have automated way to
pull and install other packages on the dependency?
^ permalink raw reply
* Re: Windows support
From: Dmitry Kakurin @ 2007-07-26 2:56 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <46A73015.7020306@midwinter.com>
On 7/25/07, Steven Grimm <koreth@midwinter.com> wrote:
> > How serious are you guys about Windows support?
> Much (nearly all?) of the core git team never touches Windows, so they
> both have no selfish motivation to get it working well and no way to
> test their changes even if they decide to take it up for the greater good.
This actually answers my question (if it's true).
If core team is not interested in supporting Windows then I cannot
trust this system with my source code :-(.
My concerns are (mostly):
* lack of (or insufficient) testing for Windows platform
* possibly lower code quality of Windows port, since core devs don't
touch it and don't care
* possible troubles with support if issues arise
* Windows port could become abandoned if those few brave people, who
work on it right now will leave
In short, all kinds of issues associated with software not being a
first class citizen :-).
- Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox