* [PATCH] gitk: fix typo when diffing committed -> staged
From: Jens Lehmann @ 2009-10-27 17:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Git Mailing List
When highlighting a commit, using the context menu over the staged changes
and then selecting "Diff this -> selected" the diff was empty. The same
happened when highlighting the staged changes and using "Diff selected ->
this" over a commit.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
I became aware of this issue while testing the submodule patch sent
earlier. Looks just like a copy & paste typo.
gitk-git/gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..8e892b3 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7224,7 +7224,7 @@ proc diffcmd {ids flags} {
set cmd [concat | git diff-index --cached $flags]
if {[llength $ids] > 1} {
# comparing index with specific revision
- if {$i == 0} {
+ if {$j == 0} {
lappend cmd -R [lindex $ids 1]
} else {
lappend cmd [lindex $ids 0]
--
1.6.5.2.181.gd6f41.dirty
^ permalink raw reply related
* Re: git-svn changing file:// to svn+ssh://
From: Sam Vilain @ 2009-10-27 17:17 UTC (permalink / raw)
To: Avery Pennarun; +Cc: pascal, git list
In-Reply-To: <32541b130910261218x5fdc0233jcce7c5769aad73ec@mail.gmail.com>
On Mon, 2009-10-26 at 15:18 -0400, Avery Pennarun wrote:
> > Now I have converted the file:// to svn+ssh:// using:
>
> I'm not sure about the actual bug you're experiencing, but you could
> have done this more simply using the --rewrite-root option to git-svn.
> It might still save you time to just do that from scratch.
Another thing: if your file:// repository was copied from the original
location using SVN::Mirror or svnsync, then git-svn is capable of
reading the breadcrumbs left by those tools with a switch and rewriting
the git-svn-id: lines accordingly.
Sam
^ permalink raw reply
* Re: [PATCH] Fix memory leak in transport-helper
From: Daniel Barkalow @ 2009-10-27 17:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, Johan Herland, Nanako Shiraishi,
Sverre Rabbelier, git
In-Reply-To: <alpine.DEB.1.00.0910271510430.4985@pacific.mpi-cbg.de>
On Tue, 27 Oct 2009, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Oct 2009, Daniel Barkalow wrote:
>
> > diff --git a/transport-helper.c b/transport-helper.c
> > index f57e84c..479539d 100644
> > --- a/transport-helper.c
> > +++ b/transport-helper.c
> > @@ -67,6 +67,13 @@ static int disconnect_helper(struct transport *transport)
> > return 0;
> > }
> >
> > +static int close_helper(struct transport *transport)
> > +{
> > + disconnect_helper(transport);
> > + free(transport->data);
> > + return 0;
> > +}
>
> Why did you not leech the transport->data = NULL; part from Peff/Sverre's
> patch?
Because this code is only called just before transport itself is freed by
the caller, and, in general, a transport with these methods is invalid
without a valid transport->data. I expect that's also why Peff called it a
hack not appropriate for actual application.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Making Git easy to use -- without RTFM, was Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Avery Pennarun @ 2009-10-27 17:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0910271118470.4985@pacific.mpi-cbg.de>
On Tue, Oct 27, 2009 at 6:33 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Anyhow, here it is: one of my users refused to touch SCMs _at all_, for
> decades. There was only one choice: have a Git branch with a purely
> linear history that contains the copy of the working tree at the end of
> the day, with whatever changes accumulated over the day, or no history at
> all.
[...]
> You know, when there is a hurdle half of the people you see cannot get
> over, there are some who make the hurdle half as high, and there are
> others who put more hurdles there and call it a sport.
>
> In this case, I would have preferred to make the hurdle half as high, but
> I think I just have to wait a couple of years; reality will take care of
> things.
In this case, what would you have preferred to change in order to make
the hurdle half as high?
Thanks,
Avery
^ permalink raw reply
* Re: vl/git-gui topic
From: Shawn O. Pearce @ 2009-10-27 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> * vl/git-gui (2009-10-16) 1 commit.
> - git-gui: adjust the minimum height of diff pane for shorter screen height
>
> Shawn?
Applied to git-gui tree.
--
Shawn.
^ permalink raw reply
* Add '--bisect' revision machinery argument
From: Linus Torvalds @ 2009-10-27 18:28 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
I personally use "git bisect visualize" all the time when I bisect, but it
turns out that that is not a very flexible model. Sometimes I want to do
bisection based on all commits (no pathname limiting), but then visualize
the current bisection tree with just a few pathnames because I _suspect_
those pathnames are involved in the problem but am not totally sure about
them.
And at other times, I want to use other revision parsing logic, none of
which is available with "git bisect visualize".
So this adds "--bisect" as a revision parsing argument, and as a result it
just works with all the normal logging tools. So now I can just do
gitk --bisect --simplify-by-decoration filename-here
etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
builtin-rev-parse.c | 11 +++++++++++
revision.c | 18 +++++++++++++++++-
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 45bead6..9526aaf 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -180,6 +180,12 @@ static int show_reference(const char *refname, const unsigned char *sha1, int fl
return 0;
}
+static int anti_reference(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ show_rev(REVERSED, sha1, refname);
+ return 0;
+}
+
static void show_datestring(const char *flag, const char *datestr)
{
static char buffer[100];
@@ -548,6 +554,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
for_each_ref(show_reference, NULL);
continue;
}
+ if (!strcmp(arg, "--bisect")) {
+ for_each_ref_in("refs/bisect/bad", show_reference, NULL);
+ for_each_ref_in("refs/bisect/good", anti_reference, NULL);
+ continue;
+ }
if (!strcmp(arg, "--branches")) {
for_each_branch_ref(show_reference, NULL);
continue;
diff --git a/revision.c b/revision.c
index 9fc4e8d..80a0528 100644
--- a/revision.c
+++ b/revision.c
@@ -994,7 +994,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
if (!strcmp(arg, "--all") || !strcmp(arg, "--branches") ||
!strcmp(arg, "--tags") || !strcmp(arg, "--remotes") ||
!strcmp(arg, "--reflog") || !strcmp(arg, "--not") ||
- !strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk"))
+ !strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk") ||
+ !strcmp(arg, "--bisect"))
{
unkv[(*unkc)++] = arg;
return 1;
@@ -1218,6 +1219,16 @@ void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
ctx->argc -= n;
}
+static int for_each_bad_bisect_ref(each_ref_fn fn, void *cb_data)
+{
+ return for_each_ref_in("refs/bisect/bad", fn, cb_data);
+}
+
+static int for_each_good_bisect_ref(each_ref_fn fn, void *cb_data)
+{
+ return for_each_ref_in("refs/bisect/good", fn, cb_data);
+}
+
/*
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
@@ -1259,6 +1270,11 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
handle_refs(revs, flags, for_each_branch_ref);
continue;
}
+ if (!strcmp(arg, "--bisect")) {
+ handle_refs(revs, flags, for_each_bad_bisect_ref);
+ handle_refs(revs, flags ^ UNINTERESTING, for_each_good_bisect_ref);
+ continue;
+ }
if (!strcmp(arg, "--tags")) {
handle_refs(revs, flags, for_each_tag_ref);
continue;
^ permalink raw reply related
* Re: [PATCH] Fix memory leak in transport-helper
From: Jeff King @ 2009-10-27 18:31 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Johannes Schindelin, Shawn O. Pearce, Junio C Hamano,
Johan Herland, Nanako Shiraishi, Sverre Rabbelier, git
In-Reply-To: <alpine.LNX.2.00.0910271329510.14365@iabervon.org>
On Tue, Oct 27, 2009 at 01:37:19PM -0400, Daniel Barkalow wrote:
> > Why did you not leech the transport->data = NULL; part from Peff/Sverre's
> > patch?
>
> Because this code is only called just before transport itself is freed by
> the caller, and, in general, a transport with these methods is invalid
> without a valid transport->data. I expect that's also why Peff called it a
> hack not appropriate for actual application.
More or less. I called it a hack because I didn't even look far enough
to know whether or not that was the case. I was just trying to get it to
stop segfaulting so Sverre could continue his work.
-Peff
^ permalink raw reply
* Re: jp/dirty-describe topic
From: Shawn O. Pearce @ 2009-10-27 18:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> * jp/dirty-describe (2009-10-21) 1 commit.
> - Teach "git describe" --dirty option
>
> Ack?
Yup,
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: git update --prune issue
From: Jeff King @ 2009-10-27 18:46 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeffrey Middleton, Michael J Gruber, git
In-Reply-To: <20091027165054.GA8554@sigill.intra.peff.net>
On Tue, Oct 27, 2009 at 12:50:55PM -0400, Jeff King wrote:
> > Actually, it's beta_gc_dev_old and beta_gc_dev, not the same refs.
>
> OK, I'm a bit blind. Thanks for pointing it out. I'll still see if I can
> replicate it.
I'm not having any luck reproducing here with a simple case. :( I'm
trying:
-- >8 --
#!/bin/sh
rm -rf parent* child
commit() {
echo $1 >file && git add file && git commit -m $1
}
mkdir parent1 && (
cd parent1 &&
git init &&
commit one &&
commit two &&
git checkout -b other
) &&
mkdir parent2 && (
cd parent2 &&
git init &&
commit three
) &&
mkdir child && (
cd child &&
git init &&
git remote add parent1 ../parent1 &&
git remote add parent2 ../parent2 &&
git remote update
) &&
(
cd parent1 &&
git checkout master &&
git branch -d other &&
git reset --hard HEAD^ &&
commit four
) && (
cd child &&
git remote update --prune
)
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Shawn O. Pearce @ 2009-10-27 18:52 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Junio C Hamano, git, Clemens Buchacher, Sverre Rabbelier
In-Reply-To: <1256589116-6998-3-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> wrote:
> Some users don't want to compile their completion, even when the build
> generated completion is 10x faster to load. For example, in my bashrc I
> source the completion script directly so I can stay up to date with the
> latest completion by merely pulling changes.
>
> Do this by generating the lists dynamically when the merge strategy and
> command lists still have their initial values (__GIT_MERGE_STRATEGYLIST,
> __GIT_ALL_COMMANDLIST).
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> This duplicates code, but I don't know of a way to re-use the dynamic
> code without sourcing a bash script and possibly breaking someone's build.
NAK on code duplication, especially this much. As Junio already
pointed out in this thread we need an approach that doesn't cause
this sort of redundant code.
I'm trying to catch up on email right now. I have no great
suggestions on how to implement this to avoid the code duplication
and still be able to support both compile-time and on-the-fly
computation, but I do know I don't want this code twice.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Fix memory leak in transport-helper
From: Johannes Schindelin @ 2009-10-27 18:54 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Shawn O. Pearce, Junio C Hamano, Johan Herland, Nanako Shiraishi,
Sverre Rabbelier, git
In-Reply-To: <alpine.LNX.2.00.0910271329510.14365@iabervon.org>
Hi,
On Tue, 27 Oct 2009, Daniel Barkalow wrote:
> On Tue, 27 Oct 2009, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Tue, 27 Oct 2009, Daniel Barkalow wrote:
> >
> > > diff --git a/transport-helper.c b/transport-helper.c
> > > index f57e84c..479539d 100644
> > > --- a/transport-helper.c
> > > +++ b/transport-helper.c
> > > @@ -67,6 +67,13 @@ static int disconnect_helper(struct transport *transport)
> > > return 0;
> > > }
> > >
> > > +static int close_helper(struct transport *transport)
> > > +{
> > > + disconnect_helper(transport);
> > > + free(transport->data);
> > > + return 0;
> > > +}
> >
> > Why did you not leech the transport->data = NULL; part from Peff/Sverre's
> > patch?
>
> Because this code is only called just before transport itself is freed by
> the caller, and, in general, a transport with these methods is invalid
> without a valid transport->data. I expect that's also why Peff called it a
> hack not appropriate for actual application.
So you mean to imply that this method is not about closing, but about
releasing the structure. Right?
Ciao,
Dscho
^ permalink raw reply
* Re: Problems with git am
From: Jeff King @ 2009-10-27 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: alan, git
In-Reply-To: <7veiopbm9l.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 07:31:34PM -0700, Junio C Hamano wrote:
> alan <alan@clueserver.org> writes:
>
> > The other question is what the proper behaviour when git-am in unable
> > to process a patch. Under git 1.6.0, it exits with a non-zero error
> > code. Under the current git in the git repo it issues and error and
> > exits with a non-error exit code.
>
> Hmph, that sounds like a recent regression to me. I'll try to find time
> to look into it myself sometime tonight but no promises.
I'm having trouble reproducing, either with a totally bogus input format
or with "git log -p" output (which is what it sounds like the OP has).
Both of these tests already pass on 'next':
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 8296605..2d5e32a 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -346,4 +346,17 @@ test_expect_success 'am -q is quiet' '
! test -s output.out
'
+test_expect_success 'am properly reports error' '
+ echo excellent > bogus &&
+ test_must_fail git am bogus
+'
+
+test_expect_success 'am properly reports error (git log output)' '
+ echo more content >>file &&
+ git commit -m content file &&
+ git log -1 -p > bogus &&
+ git reset --hard HEAD^ &&
+ test_must_fail git am bogus
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] Fix memory leak in transport-helper
From: Daniel Barkalow @ 2009-10-27 19:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, Johan Herland, Nanako Shiraishi,
Sverre Rabbelier, git
In-Reply-To: <alpine.DEB.1.00.0910271954020.11562@felix-maschine>
On Tue, 27 Oct 2009, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Oct 2009, Daniel Barkalow wrote:
>
> > On Tue, 27 Oct 2009, Johannes Schindelin wrote:
> >
> > > Hi,
> > >
> > > On Tue, 27 Oct 2009, Daniel Barkalow wrote:
> > >
> > > > diff --git a/transport-helper.c b/transport-helper.c
> > > > index f57e84c..479539d 100644
> > > > --- a/transport-helper.c
> > > > +++ b/transport-helper.c
> > > > @@ -67,6 +67,13 @@ static int disconnect_helper(struct transport *transport)
> > > > return 0;
> > > > }
> > > >
> > > > +static int close_helper(struct transport *transport)
> > > > +{
> > > > + disconnect_helper(transport);
> > > > + free(transport->data);
> > > > + return 0;
> > > > +}
> > >
> > > Why did you not leech the transport->data = NULL; part from Peff/Sverre's
> > > patch?
> >
> > Because this code is only called just before transport itself is freed by
> > the caller, and, in general, a transport with these methods is invalid
> > without a valid transport->data. I expect that's also why Peff called it a
> > hack not appropriate for actual application.
>
> So you mean to imply that this method is not about closing, but about
> releasing the structure. Right?
Yes, that's the word I was failing to come up with last night, thanks.
Junio, "s/close/release/g" on that patch should improve comprehensibility
greatly. (And changing the transport method name would probably also
improve matters)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH 0/4] Cygwin MSVC patches
From: Ramsay Jones @ 2009-10-27 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list, mstormo
Hi Junio,
I've had these patches "hanging around" in my queue, for a few
weeks, with every intention of adding several more to fix up
some problems... Hmm, well I haven't got to those yet, so I
thought I may as well pass these on.
[PATCH 1/4] MSVC: Fix an "unresolved symbol" linker error on cygwin
[PATCH 2/4] Makefile: merge two Cygwin configuration sections into one
[PATCH 3/4] Makefile: keep MSVC and Cygwin configuration separate
[PATCH 4/4] win32: Improve the conditional inclusion of WIN32 API code
I think they are all pretty safe (famous last words), but it would be
a good idea for someone with an MSYS/MinGW installation to test them
(particularly patch #4; it's really the only one I'm slightly worried
about :D).
With these patches, the msvc build on cygwin seems to be working fine.
At first it looked bad; an ./git-status showed a shed-load of "Changed
but not updated" files along with many "Untracked files" which should
have been ignored (eg editor backup files).
In order to fix the ignored files problem, I had to make a change to
~/.gitconfig. The core.excludesfile was set to /home/ramsay/.gitignore,
which (being a cygwin path) the msvc build could not read. However,
setting this to C:/cygwin/home/ramsay/.gitignore fixed the problem
since both the cygwin and msvc builds can read that path.
When ./git-diff showed that most of the "Changed" files differed only
in the mode, in particular only the execute bit, it was easy to fix
that also; set core.filemode to false.
This left only the symlink RelNotes, which was shown as deleted and an
RelNotes.lnk file as untracked. This is to be expected on a cygwin
git repo (and is an example of the "white-lies" that cygwin tells you
when it iterates over the filesystem).
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH 1/4] MSVC: Fix an "unresolved symbol" linker error on cygwin
From: Ramsay Jones @ 2009-10-27 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list, Marius Storm-Olsen
When the NO_MMAP build variable is set, which is the case by
default on cygwin, the msvc linker complains:
error LNK2001: unresolved external symbol _getpagesize
The mingw build has a version of the getpagesize() function
defined in the libgcc.a library. In addition, this function
is replaced, if USE_WIN32_MMAP is defined, by a version more
suitable for use with the native mmap.
The msvc libraries do not define any getpagesize() function,
so we move the mingw_getpagesize() implementation from the
conditionally built win32mmap.c file to mingw.c, which will
always be included in the MSVC build.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
This alone won't make the MSVC build work on cygwin; I have to
$ make MSVC=1 NEEDS_LIBICONV=
otherwise the linker complains about the absence of the iconv.lib.
(I have downloaded the win32 version of the library, but I haven't
got around to installing it! see http://gnuwin32.sourceforge.net/
packages/libiconv.htm)
The real problem, of course, is that the cygwin and MSVC configuration
sections are not mutually exclusive. (see patch 3/4)
ATB,
Ramsay Jones
compat/mingw.c | 12 ++++++++++++
compat/mingw.h | 2 +-
compat/win32mmap.c | 12 ------------
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 6b5b5b2..15fe33e 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1000,6 +1000,18 @@ repeat:
return -1;
}
+/*
+ * Note that this doesn't return the actual pagesize, but
+ * the allocation granularity. If future Windows specific git code
+ * needs the real getpagesize function, we need to find another solution.
+ */
+int mingw_getpagesize(void)
+{
+ SYSTEM_INFO si;
+ GetSystemInfo(&si);
+ return si.dwAllocationGranularity;
+}
+
struct passwd *getpwuid(int uid)
{
static char user_name[100];
diff --git a/compat/mingw.h b/compat/mingw.h
index 5b5258b..26c4027 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -166,7 +166,7 @@ int mingw_connect(int sockfd, struct sockaddr *sa, size_t sz);
int mingw_rename(const char*, const char*);
#define rename mingw_rename
-#ifdef USE_WIN32_MMAP
+#if defined(USE_WIN32_MMAP) || defined(_MSC_VER)
int mingw_getpagesize(void);
#define getpagesize mingw_getpagesize
#endif
diff --git a/compat/win32mmap.c b/compat/win32mmap.c
index 779d796..1c5a149 100644
--- a/compat/win32mmap.c
+++ b/compat/win32mmap.c
@@ -1,17 +1,5 @@
#include "../git-compat-util.h"
-/*
- * Note that this doesn't return the actual pagesize, but
- * the allocation granularity. If future Windows specific git code
- * needs the real getpagesize function, we need to find another solution.
- */
-int mingw_getpagesize(void)
-{
- SYSTEM_INFO si;
- GetSystemInfo(&si);
- return si.dwAllocationGranularity;
-}
-
void *git_mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)
{
HANDLE hmap;
--
1.6.5
^ permalink raw reply related
* [PATCH 3/4] Makefile: keep MSVC and Cygwin configuration separate
From: Ramsay Jones @ 2009-10-27 19:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list, Marius Storm-Olsen
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Makefile | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 8e1cfc5..12c8249 100644
--- a/Makefile
+++ b/Makefile
@@ -658,6 +658,14 @@ EXTLIBS =
# Platform specific tweaks
#
+ifdef MSVC
+ # When building with msvc, on MinGW or Cygwin, we
+ # override the uname settings to make it easier to
+ # keep the configuration sections separate
+ uname_S = Windows
+ uname_O = Windows
+endif
+
# We choose to avoid "if .. else if .. else .. endif endif"
# because maintaining the nesting to match is a pain. If
# we had "elif" things would have been much nicer...
@@ -893,7 +901,7 @@ ifeq ($(uname_S),HP-UX)
NO_SYS_SELECT_H = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
endif
-ifdef MSVC
+ifeq ($(uname_S),Windows)
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
NO_PREAD = YesPlease
@@ -945,7 +953,7 @@ else
BASIC_CFLAGS += -Zi -MTd
endif
X = .exe
-else
+endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
@@ -994,7 +1002,6 @@ else
NO_PTHREADS = YesPlease
endif
endif
-endif
-include config.mak.autogen
-include config.mak
--
1.6.5
^ permalink raw reply related
* [PATCH 2/4] Makefile: merge two Cygwin configuration sections into one
From: Ramsay Jones @ 2009-10-27 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list, Marius Storm-Olsen, dpotapov
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
I can't think of any potential problems with this... but I've
added Dmitry to the cc-list, since he appears to have added
the second cygwin section in adbc0b6b, just in case... ;-)
ATB,
Ramsay Jones
Makefile | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index fea237b..8e1cfc5 100644
--- a/Makefile
+++ b/Makefile
@@ -782,6 +782,8 @@ ifeq ($(uname_O),Cygwin)
NO_MMAP = YesPlease
NO_IPV6 = YesPlease
X = .exe
+ COMPAT_OBJS += compat/cygwin.o
+ UNRELIABLE_FSTAT = UnfortunatelyYes
endif
ifeq ($(uname_S),FreeBSD)
NEEDS_LIBICONV = YesPlease
@@ -891,10 +893,6 @@ ifeq ($(uname_S),HP-UX)
NO_SYS_SELECT_H = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
endif
-ifneq (,$(findstring CYGWIN,$(uname_S)))
- COMPAT_OBJS += compat/cygwin.o
- UNRELIABLE_FSTAT = UnfortunatelyYes
-endif
ifdef MSVC
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
--
1.6.5
^ permalink raw reply related
* [PATCH 4/4] win32: Improve the conditional inclusion of WIN32 API code
From: Ramsay Jones @ 2009-10-27 19:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list, Marius Storm-Olsen
After experimenting with several win32 compilers, it is clear
that the _WIN32 macro should be used to guard the inclusion
of the main WIN32 API header files, particularly in the main
git-compat-util.h header. In addition, the cygwin build should
restrict the use of the WIN32 API to compat/cygwin.c
In order to avoid mistakes with the use of WIN32 and _WIN32
macros, define a new WIN32_API macro, with a single point of
definition in git-compat-util.h, to isolate WIN32 specific
code.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/cygwin.c | 1 +
compat/snprintf.c | 2 +-
compat/win32.h | 3 ---
diff-no-index.c | 2 +-
git-compat-util.h | 9 +++++----
help.c | 2 +-
| 4 ++--
run-command.c | 8 ++++----
run-command.h | 2 +-
setup.c | 2 +-
test-chmtime.c | 2 +-
thread-utils.c | 2 +-
12 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/compat/cygwin.c b/compat/cygwin.c
index b4a51b9..6695515 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -1,5 +1,6 @@
#define WIN32_LEAN_AND_MEAN
#include "../git-compat-util.h"
+#include <windows.h>
#include "win32.h"
#include "../cache.h" /* to read configuration */
diff --git a/compat/snprintf.c b/compat/snprintf.c
index e1e0e75..373692a 100644
--- a/compat/snprintf.c
+++ b/compat/snprintf.c
@@ -9,7 +9,7 @@
* always have room for a trailing NUL byte.
*/
#ifndef SNPRINTF_SIZE_CORR
-#if defined(WIN32) && (!defined(__GNUC__) || __GNUC__ < 4)
+#if defined(WIN32_API) && (!defined(__GNUC__) || __GNUC__ < 4)
#define SNPRINTF_SIZE_CORR 1
#else
#define SNPRINTF_SIZE_CORR 0
diff --git a/compat/win32.h b/compat/win32.h
index 8ce9104..a7ed72b 100644
--- a/compat/win32.h
+++ b/compat/win32.h
@@ -2,9 +2,6 @@
#define WIN32_H
/* common Win32 functions for MinGW and Cygwin */
-#ifndef WIN32 /* Not defined by Cygwin */
-#include <windows.h>
-#endif
static inline int file_attr_to_st_mode (DWORD attr)
{
diff --git a/diff-no-index.c b/diff-no-index.c
index 4ebc1db..fca8d5d 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -38,7 +38,7 @@ static int get_mode(const char *path, int *mode)
if (!path || !strcmp(path, "/dev/null"))
*mode = 0;
-#ifdef _WIN32
+#ifdef WIN32_API
else if (!strcasecmp(path, "nul"))
*mode = 0;
#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..5792f71 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -65,10 +65,11 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
-#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
-#include <winsock2.h>
-#include <windows.h>
+#if defined(_WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */
+# define WIN32_API
+# define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
+# include <winsock2.h>
+# include <windows.h>
#endif
#include <unistd.h>
diff --git a/help.c b/help.c
index e8db31f..9fc9e69 100644
--- a/help.c
+++ b/help.c
@@ -126,7 +126,7 @@ static int is_executable(const char *name)
!S_ISREG(st.st_mode))
return 0;
-#ifdef WIN32
+#ifdef WIN32_API
{ /* cannot trust the executable bit, peek into the file instead */
char buf[3] = { 0 };
int n;
--git a/pager.c b/pager.c
index 86facec..d7aed0c 100644
--- a/pager.c
+++ b/pager.c
@@ -9,7 +9,7 @@
static int spawned_pager;
-#ifndef WIN32
+#ifndef WIN32_API
static void pager_preexec(void)
{
/*
@@ -72,7 +72,7 @@ void setup_pager(void)
static const char *env[] = { "LESS=FRSX", NULL };
pager_process.env = env;
}
-#ifndef WIN32
+#ifndef WIN32_API
pager_process.preexec_cb = pager_preexec;
#endif
if (start_command(&pager_process))
diff --git a/run-command.c b/run-command.c
index cf2d8f7..7872109 100644
--- a/run-command.c
+++ b/run-command.c
@@ -75,7 +75,7 @@ fail_pipe:
trace_argv_printf(cmd->argv, "trace: run_command:");
-#ifndef WIN32
+#ifndef WIN32_API
fflush(NULL);
cmd->pid = fork();
if (!cmd->pid) {
@@ -315,7 +315,7 @@ int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const
return run_command(&cmd);
}
-#ifdef WIN32
+#ifdef WIN32_API
static unsigned __stdcall run_thread(void *data)
{
struct async *async = data;
@@ -331,7 +331,7 @@ int start_async(struct async *async)
return error("cannot create pipe: %s", strerror(errno));
async->out = pipe_out[0];
-#ifndef WIN32
+#ifndef WIN32_API
/* Flush stdio before fork() to avoid cloning buffers */
fflush(NULL);
@@ -360,7 +360,7 @@ int start_async(struct async *async)
int finish_async(struct async *async)
{
-#ifndef WIN32
+#ifndef WIN32_API
int ret = wait_or_whine(async->pid, "child process", 0);
#else
DWORD ret = 0;
diff --git a/run-command.h b/run-command.h
index fb34209..508568d 100644
--- a/run-command.h
+++ b/run-command.h
@@ -70,7 +70,7 @@ struct async {
int (*proc)(int fd, void *data);
void *data;
int out; /* caller reads from here and closes it */
-#ifndef WIN32
+#ifndef WIN32_API
pid_t pid;
#else
HANDLE tid;
diff --git a/setup.c b/setup.c
index 029371e..08f8891 100644
--- a/setup.c
+++ b/setup.c
@@ -41,7 +41,7 @@ const char *prefix_path(const char *prefix, int len, const char *path)
const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
{
static char path[PATH_MAX];
-#ifndef WIN32
+#ifndef WIN32_API
if (!pfx || !*pfx || is_absolute_path(arg))
return arg;
memcpy(path, pfx, pfx_len);
diff --git a/test-chmtime.c b/test-chmtime.c
index fe476cb..a779f7f 100644
--- a/test-chmtime.c
+++ b/test-chmtime.c
@@ -87,7 +87,7 @@ int main(int argc, const char *argv[])
return -1;
}
-#ifdef WIN32
+#ifdef WIN32_API
if (!(sb.st_mode & S_IWUSR) &&
chmod(argv[i], sb.st_mode | S_IWUSR)) {
fprintf(stderr, "Could not make user-writable %s: %s",
diff --git a/thread-utils.c b/thread-utils.c
index 4f9c829..c99273e 100644
--- a/thread-utils.c
+++ b/thread-utils.c
@@ -23,7 +23,7 @@ int online_cpus(void)
long ncpus;
#endif
-#ifdef _WIN32
+#ifdef WIN32_API
SYSTEM_INFO info;
GetSystemInfo(&info);
--
1.6.5
^ permalink raw reply related
* DOCBOOK_SUPPRESS_SP with docbook-sxl 1.71.0
From: Ramsay Jones @ 2009-10-27 19:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list, chris_johnsen
Hi Junio,
Whenever I install a new git, I always re-build the documentation
(on Linux) rather than use the pre-built html and manpages.
(BTW, I actually don't know why; it's just a habit now:)
>From the Documentation/Makefile, it seems there may be some
speculation if DOCBOOK_SUPPRESS_SP should be set when using the
docbook-xsl version 1.71.0.
I am using asciidoc version 7.1.2 along with docbook-xsl version
1.71.0, and I can confirm that setting DOCBOOK_SUPPRESS_SP is
required. (The manpages are *unusable* otherwise)
[I'm sorry, but I don't know the xmlto version number and I can't
get to my linux box ATM]
ATB,
Ramsay Jones
^ permalink raw reply
* Re: possible usability issue in rebase -i?
From: Baz @ 2009-10-27 21:05 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List
In-Reply-To: <40aa078e0910270850u6ffec41cj372da11d9df533f@mail.gmail.com>
2009/10/27 Erik Faye-Lund <kusmabite@googlemail.com>:
> On Tue, Oct 27, 2009 at 4:17 PM, Baz <brian.ewins@gmail.com> wrote:
>> I've got a somewhat related minor usability issue with rebase -i. I
>> accidentally typed something like 'git rebase -i -z' and got this
>> message:
>>
>> error: unknown switch `z'
>> usage: git-rebase [-i] [options] [--] <upstream> [<branch>]
>> or: git-rebase [-i] (--continue | --abort | --skip)
>>
>> Available options are
>> -v, --verbose display a diffstat of what changed upstream
>> --onto ... rebase onto given branch instead of upstream
>> -p, --preserve-merges
>> try to recreate merges instead of ignoring them
>> -s, --strategy ... use the given merge strategy
>> -m, --merge always used (no-op)
>> -i, --interactive always used (no-op)
>>
>> The last two lines were the surprise. It suggested to me that '-i' and
>> '-m' were now the defaults for git-rebase - which of course they're
>> not. A user would not know that this is actually reporting the flags
>> that work for git-rebase--interactive, especially since that's not
>> what the command calls itself. I wasn't sure about the best approach
>> to fixing this - the only comparable commands that pass arbitrary
>> flags down to an exec'd program make it clear what program is going to
>> be called (usually git merge) and so interpreting errors is easier.
>>
>> It seems the intent here was to signal that the flags are different
>> once a rebase is in progress, but this usage message is shown when
>> rebase -i -z is called in any state.
>
> If that is the case, my instinct tells me that this information should
> be reflected in the usage-string (instead of the parameter
> description). Something like this?
I'm fine with this way of fixing it, but I'd make a few more changes...
>
> --->8---
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 23ded48..3ed5f94 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -13,15 +13,15 @@
> OPTIONS_KEEPDASHDASH=
> OPTIONS_SPEC="\
> git-rebase [-i] [options] [--] <upstream> [<branch>]
Use the dashless form and be more consistent with the help - and
mention '--root' here, it appears in the
help below:
-git-rebase [-i] [options] [--] <upstream> [<branch>]
+git rebase [--interactive | -i] [options] [--onto <newbase>] [--]
<upstream> [<branch>]
+git rebase [--interactive | -i] [options] --onto <newbase> --root
[--] [<branch>]
> -git-rebase [-i] (--continue | --abort | --skip)
> +git-rebase [-i] [-m] (--continue | --abort | --skip)
Again, dashless. And I'd not mention the useless -i here, the man page
doesn't either:
-git-rebase [-i] (--continue | --abort | --skip)
+git rebase (--continue | --abort | --skip)
> --
> Available options are
> v,verbose display a diffstat of what changed upstream
> onto= rebase onto given branch instead of upstream
> p,preserve-merges try to recreate merges instead of ignoring them
> s,strategy= use the given merge strategy
> -m,merge always used (no-op)
> -i,interactive always used (no-op)
> +m,merge use merging strategies
> +i,interactive interactively edit commits
These two items are misplaced in the help (I think). They're not like
abort, continue, skip, but then, the man page doesn't group those
separately either.
+no-verify override pre-rebase hook from stopping the operation
+root rebase all reachable commmits up to the root(s)
> Actions:
> continue continue rebasing process
> abort abort rebasing process and restore original branch
As above, remove the next two lines after your patch:
-no-verify override pre-rebase hook from stopping the operation
-root rebase all reachable commmits up to the root(s)
-Baz
>
> --
> Erik "kusma" Faye-Lund
>
^ permalink raw reply
* Re: [PATCH 2/4] Add I18N-wrappers for low-level IO-routines
From: Jeff King @ 2009-10-27 21:08 UTC (permalink / raw)
To: Timur Sufiev; +Cc: git
In-Reply-To: <1256651643-18382-2-git-send-email-timur@iris-comp.ru>
On Tue, Oct 27, 2009 at 04:54:01PM +0300, Timur Sufiev wrote:
> Signed-off-by: Timur Sufiev <timur@iris-comp.ru>
Hmm. Two questions about this series:
1. Patch 3/4 didn't seem to make it to the list. Presumably that is
where you actually use these routines in git? Or are they just for
mingw?
2. I seem to recall that Linus added a filename translation layer for
doing much more, like handling unicode normalizations (but I
confess I haven't looked closely at that code). Should this be part
of that system?
-Peff
^ permalink raw reply
* Re: [PATCH 7/6 (v4)] support for commit grafts, slight change to general mechanism
From: Nick Edelen @ 2009-10-27 21:11 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, Sam Vilain,
Michael J Gruber, Jeff King, Shawn O. Pearce, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <200910211115.25017.trast@student.ethz.ch>
> I felt adventurous and merged the topic into my local build, but I get
> "error: duplicate graft data ..." in repositories with only a single
> line in .git/info/grafts, which bisects to this commit (1c0a666 in
> today's pu).
Oops, it looks like there's a bug in my bugfix... I had
parse_commit() accidentally calling itself through
register_commit_graft(); fixed now though. Thanks for giving it a try
though!
^ permalink raw reply
* Re: My custom cccmd
From: Junio C Hamano @ 2009-10-27 21:53 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530910250804w3a7da36eke10710eb1cbb03c1@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> I explored this a bit more and I've come to the conclusion that we
> actually don't wand to discard the previous commits in the patch
> series. Let's think about this example:
> 0001 <- John
> 0002 <- Me overriding some changes from John
>
> In this case we want John to appear in the CC list of 0002, because we
> are changing his code.
There are two cases: your patch partially overrides his code, and your
patch completely rewrites/removes his code.
Obviously in the former case you do want to Cc, but there are parts of his
change that remain in the final result, so this case does not matter in
this discussion. You will Cc him because of these remaining lines anyway.
In the latter case, the only contribution that remains from him is a
commit with his log message that does not help describing anything in the
end result, cluttering the history.
In such a case, I would imagine that the reviewers would want to see a
cleaned up series that does not have his patch that is irrelevant for
understanding the final result. John might want to know about it, if only
to raise objection to the way how you arranged your series. For that
reason, I think it makes sense to Cc him.
But it is a rather a convoluted logic, if you ask me. You find John and
Cc him, primarily so that he can point out that you should be redoing the
series not to have his patch as an intermediate state in the series to
begin with, because his commit does not contribute to the end result.
It might make more sense if your tool told you about such a case directly,
rather than helping you find John so that he can tell you ;-).
^ permalink raw reply
* Re: [PATCH 5/5] http-backend: more explict LocationMatch
From: Shawn O. Pearce @ 2009-10-27 22:24 UTC (permalink / raw)
To: Mark Lodato; +Cc: git, Junio C Hamano
In-Reply-To: <1256493935-8680-6-git-send-email-lodatom@gmail.com>
Mark Lodato <lodatom@gmail.com> wrote:
> In the git-http-backend examples, only match git-receive-pack within
> /git/.
All 5 patches:
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Junio, add these to my smart-http topic please. :-)
Thanks Mark!
--
Shawn.
^ permalink raw reply
* Re: [PATCH] push: support remote branches in guess_ref DWIM
From: Junio C Hamano @ 2009-10-27 22:33 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091027014525.GA29583@sigio.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Oct 26, 2009 at 04:31:57PM -0700, Junio C Hamano wrote:
>
>> As _our_ origin can never be _their_ origin if we are clone of them, I do
>> not think anybody sane would expect it to push into refs/remotes/origin/
>> to begin with.
>
> OK, I agree.
>
>> But "not in refs/remotes/" does not automatically mean "the only sensible
>> place is refs/heads", does it? "We do not know what kind of mistake the
>> user is trying to make" could be more plausible answer, and in that case,
>> "complain and die" may be a more valid course of action.
>
> The thing is that I can't think of another sensible place. And this
> sensible place is useful for one particular action: renaming a remote
> branch, like this:
>
> $ git fetch ;# presumably gets origin/branch
> $ git push origin/branch:renamed-branch
>
> which is much nicer than exposing clueless users to
> ":refs/heads/renamed-branch".
You would need to expose ":refs/heads/branch" to make this a rename, not a
copy, wouldn't you?
>> For example,
>>
>> git push origin origin/master:refs/heads/master
>>
>> is most likely to be a mistake. The only situation something similar to
>> this makes sense is where you pushed out a bogus commit earlier and are
>> trying to correct it perhaps with
>
> I'm not sure why it's likely to be a mistake.
> ...
> Am I missing some part of your argument?
I do not see much point (other than your "rename" example) in pushing what
you got from the other end without changing anything yourself back to the
same remote.
There was a thread in which people argued that the primary thing that is
dangerous in this sequence
$ git checkout origin/next; work-commit; work-commit; ...
is when you leave the detached HEAD state without saving it to a local
branch. I think what is more dangerous is that it will not give the user
a solid understanding that these commits do _not_ change origin/next in
any way. After doing the above, it is understandable that a novice would
mistakenly think: "I started from origin/next and built some, let's push
the result".
Side note: This is the reason why I think Dscho's "git checkout
next" that dwims to "-t -b next origin/next" is OK (perhaps on the
right side of the borderline), because it is more clear that this
is about creating and using your own "next", compared to the
existing "-t origin/next" shorthand. The latter risks imprinting
a misconception on an uninitiated that we are somehow working on
origin/next.
With such a misconception, you will see the likely mistake here, too:
$ git push origin origin/next:refs/heads/next
If "rename" is the _only_ valid reason you might want to push what you got
from there back to the same remote, _and_ if "rename" is something very
often needed, I think we would prefer to have a way to support that
operation directly, instead of more general DWIM that would risk passing
mistakes like the above unwarned.
> ... But I'm not sure why
> you would accidentally provide something in refs/remotes, or not want to
> be pushing to refs/heads. Where _else_ do you push, except for tags?
The above "checking out origin/next" illustrates the mistake on the $src
side, not on the $dst side. That's why my alternative solution in the
previous message was to see the type of $src and push commits to local
branches, exactly because "where else do you push".
IOW, it's between "prevent push with dubious $src from happening in the
first place" vs "give them rope". Historically I always sided with the
latter camp, but I am trying to play a devil's advocate for a change ;-).
^ 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