* Re: [PATCH 1/3] bash-completion: Support running when set -u is enabled
From: Shawn O. Pearce @ 2009-01-15 15:34 UTC (permalink / raw)
To: ted; +Cc: git, gitster
In-Reply-To: <1231963342-24461-1-git-send-email-ted@tedpavlic.com>
ted@tedpavlic.com wrote:
> From: Ted Pavlic <ted@tedpavlic.com>
>
> Under "set -u" semantics, it is an error to access undefined
> variables. Some user environments may enable this setting in the
> interactive shell.
>
> In any context where the completion functions access an undefined
> variable, accessing a default empty string (aka "${1-}" instead of
> "$1") is a reasonable way to code the function, as it silences
> the undefined variable error while still supplying an empty string.
>
> In this patch, functions that should always take an argument still use
> $1. Functions that have optional arguments use ${1-}.
>
> Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
Yup. This patch isn't as bad as everyone made it out to be.
I think we should go ahead and include it.
But usually we don't indent the commit message like you did
above; instead the message should be aligned on the left margin at
column 0. git log will indent the message during display, hence
any identation you add in the patch email just makes the message
that much harder to read from git log.
> ---
> contrib/completion/git-completion.bash | 18 +++++++++---------
> 1 files changed, 9 insertions(+), 9 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: cygwin git diff crash
From: Johannes Schindelin @ 2009-01-15 15:34 UTC (permalink / raw)
To: Jeremy Ramer; +Cc: Git Mailing List
In-Reply-To: <b9fd99020901150642i2e61bb78yf2dab2b8713592df@mail.gmail.com>
Hi,
On Thu, 15 Jan 2009, Jeremy Ramer wrote:
> On Wed, Jan 14, 2009 at 3:33 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 14 Jan 2009, Jeremy Ramer wrote:
> >
> >> Ok this is a weird issue and it's probably cygwin's fault, but I
> >> haven't found any way to fix it so I' thought I would throw it out
> >> here for comment.
> >>
> >> I am using git 1.6.0.4 on cygwin. I have a repo where if any file has
> >> changes and git detects as mode 100644 I get this error:
> >> $git diff
> >> 3 [main] git 2744 C:\cygwin\bin\git.exe: *** fatal error - could
> >> not load user32, Win32 error
> >>
> >> If I change the mode to 100755 git diff will work fine.
> >> $chmod a+x test.cpp
> >> $git diff
> >> diff --git a/test.cpp b/test.cpp
> >> old mode 100644
> >> new mode 100755
> >> index 7c0dfcd..20987a7
> >> --- a/test.cpp
> >> +++ b/test.cpp
> >> @@ -6,9 +6,11 @@ int main()
> >>
> >> void func()
> >> {
> >> + int a;^M
> >> }
> >>
> >> void func2()
> >> {
> >> + int b;^M
> >> }
> >>
> >> Anybody have a clue as to why this might occur? I have seen this in
> >> many of the repo's I use, but it is not repeatable. I tried making a
> >> test repo but could not reproduce.
> >
> > Wow, that _is_ weird. Does your test suite pass?
> >
> > Ciao,
> > Dscho
> >
>
> Forgive my ignorance, but I am not sure how to run the test suite. I
> did a quick google search but didn't find anything. I am using
> cygwin's packaged version of git and am not building it from source,
> so maybe the suite is not available. If I get a chance I will try
> building from source.
It is really easy: just make sure that make, gcc, libiconv-dev,
openssl-dev and libcurl-dev are installed (that's it AFAIR), then download
a tarball, e.g.
http://repo.or.cz/w/git.git?a=snapshot;h=next;sf=tgz
unpack it, cd to it and run "make". (I would _not_ run configure...)
Hth,
Dscho
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Sitaram Chamarty @ 2009-01-15 15:21 UTC (permalink / raw)
To: git
In-Reply-To: <20090115150913.GE10045@leksak.fem-net>
On 2009-01-15, Stephan Beyer <s-beyer@gmx.net> wrote:
> Sitaram Chamarty wrote:
>> What is the significance of test_tick? I can see what it is
>> doing, but am trying to understand why.
> So setting the time and counting it artificially up is nice
> to get the same SHAs over and over.
I should have been clearer...
I was trying to understand why the "counting up" part is
needed.
Regards,
Sitaram
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Sitaram Chamarty @ 2009-01-15 15:14 UTC (permalink / raw)
To: git
In-Reply-To: <496F3C99.1040800@drmicha.warpmail.net>
On 2009-01-15, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Second, what result do you expect? If the merge is to be preserved then
I don't know. I did this while trying to understand where
and how "-p" makes a difference. If there's anything you
can point me to that explains rebase -p, especially from a
"here's where it comes useful" point of view, I'd appreciate
it.
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Stephan Beyer @ 2009-01-15 15:09 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngmujc4.sf.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty wrote:
> On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I turned this into a proper test case (to show what would be most helpful
> > if you report bugs like this in the future).
>
> Thanks. I'll keep that in mind.
>
> What is the significance of test_tick? I can see what it is
> doing, but am trying to understand why.
When you run the test case a second, third, fourth time, the commit
times would be all different without test_tick. This is bad for
bugfixing when you need to inspect the test case repo a little
further. (When the commit times change, the commit ids change,
too.)
So setting the time and counting it artificially up is nice
to get the same SHAs over and over.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.13
From: Jonas Fonseca @ 2009-01-15 15:08 UTC (permalink / raw)
To: git
In-Reply-To: <20090115145003.GA6938@b2j>
bill lam <cbill.lam@gmail.com> wrote Thu, Jan 15, 2009:
> On Thu, 15 Jan 2009, Jonas Fonseca wrote:
> > presence of a {/usr/incude/}ncursesw/ncurses.h header. Where are the
> > unicode ncurses.h files found on your system?
>
> on ubuntu,
> /usr/incude/ncursesw/curses.h
> /usr/incude/ncursesw/ncurses.h ( just a sym link to curses.h above )
Then I am puzzled why the configure script doesn't find it. Can you send
me your config.log and the output of running configure. Maybe off-list.
--
Jonas Fonseca
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.13
From: Adeodato Simó @ 2009-01-15 15:05 UTC (permalink / raw)
To: git
In-Reply-To: <20090115145003.GA6938@b2j>
* bill lam [Thu, 15 Jan 2009 22:50:03 +0800]:
> On Thu, 15 Jan 2009, Jonas Fonseca wrote:
> > presence of a {/usr/incude/}ncursesw/ncurses.h header. Where are the
> > unicode ncurses.h files found on your system?
> on ubuntu,
> /usr/incude/ncursesw/curses.h
> /usr/incude/ncursesw/ncurses.h ( just a sym link to curses.h above )
You should send the output of ./configure, and publish the resulting
config.log file somewhere.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Man is certainly stark mad; he cannot make a flea, yet he makes gods by the
dozens.
-- Michel de Montaigne
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Sitaram Chamarty @ 2009-01-15 15:03 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901151448120.3586@pacific.mpi-cbg.de>
On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Remember: there is code that is so simple that it has no obvious flaws,
> and there is code that is so complicated that it has no obvious flaws.
I've always heard the first part as "obviously no flaws"...
^ permalink raw reply
* [PATCH 1/2] Move run_hook() from builtin-commit.c into run-command.c (libgit)
From: Stephan Beyer @ 2009-01-15 15:00 UTC (permalink / raw)
To: git
Cc: Paolo Bonzini, Miklos Vajna, Shawn O. Pearce, Daniel Barkalow,
Christian Couder, gitster, Stephan Beyer
A function that runs a hook is used in several Git commands.
builtin-commit.c has the one that is most general for cases without
piping. This patch moves it into libgit and lets the other builtins
use this libified run_hook().
Note: The run_hook() in receive-pack.c feeds the standard input of
the pre-receive or post-receive hook. So that function is renamed
to run_receive_hook().
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
This patch exists because I needed some run_hook() in sequencer
and I noticed that slight variations are used across other
builtins. :-)
Stripping out a libified version seemed better to me than
copy and paste.
builtin-commit.c | 34 ----------------------------------
builtin-gc.c | 30 +-----------------------------
builtin-merge.c | 31 +------------------------------
builtin-receive-pack.c | 6 +++---
run-command.c | 35 +++++++++++++++++++++++++++++++++++
run-command.h | 2 ++
6 files changed, 42 insertions(+), 96 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index e88b78f..6f8d9fb 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -361,40 +361,6 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
return s.commitable;
}
-static int run_hook(const char *index_file, const char *name, ...)
-{
- struct child_process hook;
- const char *argv[10], *env[2];
- char index[PATH_MAX];
- va_list args;
- int i;
-
- va_start(args, name);
- argv[0] = git_path("hooks/%s", name);
- i = 0;
- do {
- if (++i >= ARRAY_SIZE(argv))
- die ("run_hook(): too many arguments");
- argv[i] = va_arg(args, const char *);
- } while (argv[i]);
- va_end(args);
-
- snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
- env[0] = index;
- env[1] = NULL;
-
- if (access(argv[0], X_OK) < 0)
- return 0;
-
- memset(&hook, 0, sizeof(hook));
- hook.argv = argv;
- hook.no_stdin = 1;
- hook.stdout_to_stderr = 1;
- hook.env = env;
-
- return run_command(&hook);
-}
-
static int is_a_merge(const unsigned char *sha1)
{
struct commit *commit = lookup_commit(sha1);
diff --git a/builtin-gc.c b/builtin-gc.c
index f8eae4a..a201438 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -144,34 +144,6 @@ static int too_many_packs(void)
return gc_auto_pack_limit <= cnt;
}
-static int run_hook(void)
-{
- const char *argv[2];
- struct child_process hook;
- int ret;
-
- argv[0] = git_path("hooks/pre-auto-gc");
- argv[1] = NULL;
-
- if (access(argv[0], X_OK) < 0)
- return 0;
-
- memset(&hook, 0, sizeof(hook));
- hook.argv = argv;
- hook.no_stdin = 1;
- hook.stdout_to_stderr = 1;
-
- ret = start_command(&hook);
- if (ret) {
- warning("Could not spawn %s", argv[0]);
- return ret;
- }
- ret = finish_command(&hook);
- if (ret == -ERR_RUN_COMMAND_WAITPID_SIGNAL)
- warning("%s exited due to uncaught signal", argv[0]);
- return ret;
-}
-
static int need_to_gc(void)
{
/*
@@ -194,7 +166,7 @@ static int need_to_gc(void)
else if (!too_many_loose_objects())
return 0;
- if (run_hook())
+ if (run_hook(NULL, "pre-auto-gc", NULL))
return 0;
return 1;
}
diff --git a/builtin-merge.c b/builtin-merge.c
index cf86975..e4555b0 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -300,35 +300,6 @@ static void squash_message(void)
strbuf_release(&out);
}
-static int run_hook(const char *name)
-{
- struct child_process hook;
- const char *argv[3], *env[2];
- char index[PATH_MAX];
-
- argv[0] = git_path("hooks/%s", name);
- if (access(argv[0], X_OK) < 0)
- return 0;
-
- snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", get_index_file());
- env[0] = index;
- env[1] = NULL;
-
- if (squash)
- argv[1] = "1";
- else
- argv[1] = "0";
- argv[2] = NULL;
-
- memset(&hook, 0, sizeof(hook));
- hook.argv = argv;
- hook.no_stdin = 1;
- hook.stdout_to_stderr = 1;
- hook.env = env;
-
- return run_command(&hook);
-}
-
static void finish(const unsigned char *new_head, const char *msg)
{
struct strbuf reflog_message = STRBUF_INIT;
@@ -374,7 +345,7 @@ static void finish(const unsigned char *new_head, const char *msg)
}
/* Run a post-merge hook */
- run_hook("post-merge");
+ run_hook(NULL, "post-merge", squash ? "1" : "0", NULL);
strbuf_release(&reflog_message);
}
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index db67c31..6564a97 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -136,7 +136,7 @@ static int hook_status(int code, const char *hook_name)
}
}
-static int run_hook(const char *hook_name)
+static int run_receive_hook(const char *hook_name)
{
static char buf[sizeof(commands->old_sha1) * 2 + PATH_MAX + 4];
struct command *cmd;
@@ -358,7 +358,7 @@ static void execute_commands(const char *unpacker_error)
return;
}
- if (run_hook(pre_receive_hook)) {
+ if (run_receive_hook(pre_receive_hook)) {
while (cmd) {
cmd->error_string = "pre-receive hook declined";
cmd = cmd->next;
@@ -627,7 +627,7 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
unlink(pack_lockfile);
if (report_status)
report(unpack_status);
- run_hook(post_receive_hook);
+ run_receive_hook(post_receive_hook);
run_update_post_hook(commands);
}
return 0;
diff --git a/run-command.c b/run-command.c
index c90cdc5..602fe85 100644
--- a/run-command.c
+++ b/run-command.c
@@ -342,3 +342,38 @@ int finish_async(struct async *async)
#endif
return ret;
}
+
+int run_hook(const char *index_file, const char *name, ...)
+{
+ struct child_process hook;
+ const char *argv[10], *env[2];
+ char index[PATH_MAX];
+ va_list args;
+ int i;
+
+ va_start(args, name);
+ argv[0] = git_path("hooks/%s", name);
+ i = 0;
+ do {
+ if (++i >= ARRAY_SIZE(argv))
+ die("run_hook(): too many arguments");
+ argv[i] = va_arg(args, const char *);
+ } while (argv[i]);
+ va_end(args);
+
+ if (access(argv[0], X_OK) < 0)
+ return 0;
+
+ memset(&hook, 0, sizeof(hook));
+ hook.argv = argv;
+ hook.no_stdin = 1;
+ hook.stdout_to_stderr = 1;
+ if (index_file) {
+ snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
+ env[0] = index;
+ env[1] = NULL;
+ hook.env = env;
+ }
+
+ return run_command(&hook);
+}
diff --git a/run-command.h b/run-command.h
index a8b0c20..0211e1d 100644
--- a/run-command.h
+++ b/run-command.h
@@ -49,6 +49,8 @@ int start_command(struct child_process *);
int finish_command(struct child_process *);
int run_command(struct child_process *);
+extern int run_hook(const char *index_file, const char *name, ...);
+
#define RUN_COMMAND_NO_STDIN 1
#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
#define RUN_COMMAND_STDOUT_TO_STDERR 4
--
1.6.1.160.gecdb
^ permalink raw reply related
* [PATCH 2/2] api-run-command.txt: talk about run_hook()
From: Stephan Beyer @ 2009-01-15 15:00 UTC (permalink / raw)
To: git
Cc: Paolo Bonzini, Miklos Vajna, Shawn O. Pearce, Daniel Barkalow,
Christian Couder, gitster, Stephan Beyer
In-Reply-To: <1232031618-5243-1-git-send-email-s-beyer@gmx.net>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
I noticed that the last patch is lacking some documentation.
Here it is. Should perhaps be squashed.
Documentation/technical/api-run-command.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt
index 82e9e83..1241f48 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -52,6 +52,22 @@ Functions
Wait for the completion of an asynchronous function that was
started with start_async().
+`run_hook`::
+
+ Run a hook.
+ The first argument is a string to an index file or NULL
+ if the default index file or no index is used at all.
+ The second argument is the name of the hook.
+ The further variable number (up to 9) of arguments correspond
+ to the hook arguments.
+ The last argument has to be NULL to terminate the variable
+ arguments list.
+ If the hook is not executable, the return value is zero.
+ If it is executable, the hook will be executed and the exit
+ status of the hook is returned.
+ On execution, .stdout_to_stderr and .no_stdin will be set.
+ (See below.)
+
Data structures
---------------
--
1.6.1.160.gecdb
^ permalink raw reply related
* Re: [STGIT][PATCH] new: translate non word characters in patch name to '-'
From: David Kågedal @ 2009-01-15 14:53 UTC (permalink / raw)
To: git
In-Reply-To: <154e089b0812291215h72dfe04aod080f665eb7f5592@mail.gmail.com>
"Hannes Eder" <hannes@hanneseder.net> writes:
> On 12/28/08, Karl Hasselström <kha@treskal.com> wrote:
>> On 2008-12-27 13:37:20 +0100, Hannes Eder wrote:
>>
>> > This allows following usage:
>> >
>> > $ stg new full/path/file-fix-foobar
>> > Now at patch "full-path-file-fix-foobar"
>> >
>> > Signed-off-by: Hannes Eder <hannes@hanneseder.net>
>> > ---
>> >
>> > I ran into as a '/' in a patch messed up stgit.
>> >
>> > I find this useful as 'stg uncommit' does the same translation.
>>
>>
>> Clearly, bad path names shouldn't mess anything up -- see
>>
>> https://gna.org/bugs/?10919
>>
>> But I would prefer "stg new" to quit with an error message when given
>> an illegal patch name, not silently mangle it. (Of course, the
>> commands that generate patch names from commit messages -- such as
>> "stg new" when not given an explicit patch name -- should mangle the
>> commit message as much as necessary. But when the user gives us a
>> patch name, we should either use that as is or fail with an
>> informative message.)
>>
>> I think the right thing to do would be to construct a function that
>> validates patch names (I don't think we have one right now), and then
>> call it whenever we need to check if a patch name is OK. Such as when
>> the user gives us the name of a new patch. And when we've
>> auto-generated a patch name from a commit message, we should probably
>> assert that that the check function is OK with the name.
>
> What about instead of 'fail with an informative message', just issue a
> warning that
> the name has been mangled. I use pathnames in patch names frequently,
> so this would be very handy.
No, I agree with Karl. For example, a tool (such as the Emacs
frontend) might want to do a "stg new foobar" and then do something
with the patch it now knows is called "foobar". And if it was called
something else the tool will fail.
--
David Kågedal
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Sitaram Chamarty @ 2009-01-15 14:51 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901151429440.3586@pacific.mpi-cbg.de>
On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I turned this into a proper test case (to show what would be most helpful
> if you report bugs like this in the future).
Thanks. I'll keep that in mind.
What is the significance of test_tick? I can see what it is
doing, but am trying to understand why.
Regards,
Sitaram
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.13
From: bill lam @ 2009-01-15 14:50 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20090115130659.GA18081@diku.dk>
On Thu, 15 Jan 2009, Jonas Fonseca wrote:
> presence of a {/usr/incude/}ncursesw/ncurses.h header. Where are the
> unicode ncurses.h files found on your system?
on ubuntu,
/usr/incude/ncursesw/curses.h
/usr/incude/ncursesw/ncurses.h ( just a sym link to curses.h above )
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩286 張祜 題金陵渡
金陵津渡小山樓 一宿行人自可愁 潮落夜江斜月裡 兩三星火是瓜州
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Michael J Gruber @ 2009-01-15 14:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stephan Beyer, Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <alpine.DEB.1.00.0901151518520.3586@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 15.01.2009 15:25:
> Hi,
>
> On Thu, 15 Jan 2009, Michael J Gruber wrote:
>
>> Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:
>>
>>>> First of all: git 1.6.0.6 gives you the unchanged graph after using
>>>> rebase -i -p.
>>> This is true and it is a far better behavior than now, but I think it's
>>> not the expected behavior. (I have written about the behavior I'd expect
>>> in another reply to the original mail.)
>> Yep, I think -p should preserve only merges in side branches
>
> you mean everything in master..work?
>
>> (and therefore produce what you suggest, and what you get without -p).
>> If it preserves all merges then there is nothing to rewrite here.
>
> The merge _is_ outside of master, so I do not understand what the heck you
> are talking about.
Easy Dscho, easy ;)
[meaning "take it such..."]
I'm not sure what -p is supposed to do:
A) Should it preserve all merge commits which it would need to rewrite?
That is lot to ask. Previous behaviour (intended or not) seemed to be to
do nothing in this case where the merge connects master and work.
B) Should it preserve only merges in side branches? I seem to mean by
that branches where the parents are on work and other branches but not
on master.
So at least on my side there is confusion about the intention behind
'-p' (say design goal), and therefore about the expectation.
> The more I think about it, I think it's possible I broke it with the
> introduction of the "noop".
>
> However, there could be a _different_ test case where the current -p
> handling shows the same error. Dunno.
It certainly worked after the noop introduction before the r-i-p series,
but not any more after. "worked" meaning it at least didn't leave out
commits in this case (but reproduced the existing DAG). I'm getting the
impression you suggest R.I.P. for r-i-p series ;) Fine with me...
Cheers,
Michael
^ permalink raw reply
* Re: cygwin git diff crash
From: Jeremy Ramer @ 2009-01-15 14:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901142333200.3586@pacific.mpi-cbg.de>
On Wed, Jan 14, 2009 at 3:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 14 Jan 2009, Jeremy Ramer wrote:
>
>> Ok this is a weird issue and it's probably cygwin's fault, but I
>> haven't found any way to fix it so I' thought I would throw it out
>> here for comment.
>>
>> I am using git 1.6.0.4 on cygwin. I have a repo where if any file has
>> changes and git detects as mode 100644 I get this error:
>> $git diff
>> 3 [main] git 2744 C:\cygwin\bin\git.exe: *** fatal error - could
>> not load user32, Win32 error
>>
>> If I change the mode to 100755 git diff will work fine.
>> $chmod a+x test.cpp
>> $git diff
>> diff --git a/test.cpp b/test.cpp
>> old mode 100644
>> new mode 100755
>> index 7c0dfcd..20987a7
>> --- a/test.cpp
>> +++ b/test.cpp
>> @@ -6,9 +6,11 @@ int main()
>>
>> void func()
>> {
>> + int a;^M
>> }
>>
>> void func2()
>> {
>> + int b;^M
>> }
>>
>> Anybody have a clue as to why this might occur? I have seen this in
>> many of the repo's I use, but it is not repeatable. I tried making a
>> test repo but could not reproduce.
>
> Wow, that _is_ weird. Does your test suite pass?
>
> Ciao,
> Dscho
>
Forgive my ignorance, but I am not sure how to run the test suite. I
did a quick google search but didn't find anything. I am using
cygwin's packaged version of git and am not building it from source,
so maybe the suite is not available. If I get a chance I will try
building from source.
Jeremy
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Stephan Beyer @ 2009-01-15 14:40 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <496F44AC.2060607@drmicha.warpmail.net>
Michael J Gruber wrote:
> BTW: How does the sequencer based rebase do in this case,
This was the first thing I checked :-)
I had to rework the rebase -i -p code for sequencer a bit, but this
case was not something I had thought about (although it may not be
too seldom), so I'm glad it comes up now.
The result is that it eats the commits a3 and a4. (But at least it does
the same with and without --onto master.) :-)
I think it's not too hard to fix.
> and what's the general status?
I'm currently highly motivated to get it done soon and I hope that it
gets into pu or next before the end of January.
Depending on how productive I am over the weekend and depending on how
many further bugs (often hidden in such special cases) I find, it
could be sent to the list next week.
> If it's about to be integrated we can do without the
> present script...
I think it will take some time and some discussions on the list until
it will be integrated. I remember, for example, Dscho, who has, since
it had first come up, always been opposed to the mark-reset /
mark-reset-merge scheme (in rebase -i -p, at least).
Other users said "Wow, this is much more flexible." ...
and this is perhaps only one thing that can lead to some bigger
discussion.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [Q] git rebase -i -p conflicts with squash
From: Constantine Plotnikov @ 2009-01-15 14:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901150137070.3586@pacific.mpi-cbg.de>
Here is a reproduction recipe:
Goto to some empty directory and do the following commands on (cygwin,
git 1.6.0.4):
git init
echo data1 > f.txt
git add f.txt
git commit -m second
echo data2 >> f.txt
git add f.txt
git commit -m second
echo data3 >> f.txt
git add f.txt
git commit -m third
echo '#!/usr/bin/sh' >myed.sh
echo "echo -e '2\ns/pick/s/\np\nw\nq' | ed \$1" >>myed.sh
chmod a+x myed.sh
export GIT_EDITOR=`pwd`/myed.sh
git rebase -p -i master~2
The git rebase will exit with error writing something like the
following on stderr:
Refusing to squash a merge: 3b9e0d80da20e3543225679906be1cc5cf1a9f44
Constantine
On Thu, Jan 15, 2009 at 3:38 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 14 Jan 2009, Constantine Plotnikov wrote:
>
>> If I run git rebase --interactive with --preserve-merges option and
>> select "squash" for one of the commit, the rebase process fails with the
>> message "Refusing to squash a merge:
>> 5e775c536654640c173ba71a0af7e84bf8bc618a". However the neither commit
>> participating in the squash is a merge commit. Even more, there are no
>> merge commits in the repository at all.
>>
>> From my limited understanding of squash operation, it should fail only
>> if one of squashed commits is a merge commit, but it should be possible
>> to squash non-merge commits without problem as it looks like quite safe
>> and local operation (and I might want to preserve merges that happened
>> after squashed commits). Is it the current behaviour a bug or a feature?
>
> From your description, it seems that you are hitting an ordering bug of
> rebase -i -p.
>
> But without a reproduction recipe (preferably as a patch against our
> testsuite), I cannot tell.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Johannes Schindelin @ 2009-01-15 14:25 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Stephan Beyer, Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <496F44AC.2060607@drmicha.warpmail.net>
Hi,
On Thu, 15 Jan 2009, Michael J Gruber wrote:
> Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:
>
> >> First of all: git 1.6.0.6 gives you the unchanged graph after using
> >> rebase -i -p.
> >
> > This is true and it is a far better behavior than now, but I think it's
> > not the expected behavior. (I have written about the behavior I'd expect
> > in another reply to the original mail.)
>
> Yep, I think -p should preserve only merges in side branches
you mean everything in master..work?
> (and therefore produce what you suggest, and what you get without -p).
> If it preserves all merges then there is nothing to rewrite here.
The merge _is_ outside of master, so I do not understand what the heck you
are talking about.
The more I think about it, I think it's possible I broke it with the
introduction of the "noop".
However, there could be a _different_ test case where the current -p
handling shows the same error. Dunno.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 14:17 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901151508540.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 15 Jan 2009, Johannes Schindelin wrote:
> [PATCH] pack-objects --all: include HEAD, which could be detached
In hind sight, it would probably be better to add this to revision.c.
Ciao,
Dscho
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Michael J Gruber @ 2009-01-15 14:14 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <20090115135518.GB10045@leksak.fem-net>
Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:
> Hi,
>
>> First of all: git 1.6.0.6 gives you the unchanged graph after using
>> rebase -i -p.
>
> This is true and it is a far better behavior than now, but I think it's
> not the expected behavior. (I have written about the behavior I'd expect
> in another reply to the original mail.)
Yep, I think -p should preserve only merges in side branches (and
therefore produce what you suggest, and what you get without -p). If it
preserves all merges then there is nothing to rewrite here.
BTW: How does the sequencer based rebase do in this case, and what's the
general status? If it's about to be integrated we can do without the
present script...
Michael
^ permalink raw reply
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 14:14 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200901151501.26394.trast@student.ethz.ch>
Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
> > On Thu, 15 Jan 2009, Thomas Rast wrote:
> >
> > > Let git-checkout save the old branch as a symref in LAST_HEAD, and
> > > make 'git checkout -' switch back to LAST_HEAD, like 'cd -' does in
> > > the shell.
> >
> > Actually, what you want is in the reflog, no? So... parsing
> > .git/logs/HEAD for the latest occurrence of "checkout: moving from " and
> > then using everything up until the next space should give you the branch
> > name, right?
>
> It just feels wrong to grab that information from there; it's a
> free-form comment field for user consumption. And it wasn't even that
> hard to implement a LAST_HEAD.
There are a number of issues why I would like to avoid introducing
LAST_HEAD:
- it does not work when you are using different Git versions on the same
repository,
- it does not work when you switched recently,
- you are storing redundant information,
- yes, the field is meant for user consumption, but no, it is not
free-form,
- AFAICT your version could never be convinced to resurrect deleted
branches, without resorting to reflogs anyway.
- the reflog method reflects pretty much exactly how people work around
the lack of "checkout -" currently, so why not just use the same proven
approach?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 14:09 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <200901151500.01876.trast@student.ethz.ch>
Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
> > On Thu, 15 Jan 2009, Johannes Sixt wrote:
> > > You must make sure that commits referenced by LAST_HEAD are not
> > > garbage-collected. (I don't know if this happens anyway for symrefs in .git.)
> >
> > Note: if you used reflogs for that feature, the garbage collection could
> > not have killed the commit. However, it is quite possible that the
> > branch was deleted.
>
> Suddenly I'm not so sure about either behaviour any more.
>
> Consider:
>
> $ git commit -m initial
> [master (root-commit)]: created 812c476: "initial"
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 foo
> $ git checkout $(git rev-parse HEAD)
> Note: moving to "812c476ca23e25efa7e4d7081153ba657a127d95" which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b <new_branch_name>
> HEAD is now at 812c476... initial
> $ git branch -D master
> Deleted branch master (812c476).
> $ git for-each-ref
> $ git reflog expire --expire=now --all
> $ git prune --expire now
> $ git show
> fatal: bad object HEAD
> $ git show 812c476
> fatal: ambiguous argument '812c476': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> Oops.
>
> Some quick RTFS shows that it indeed "only" cares about refs and
> reflogs.
Maybe something like this would help (completely untested, though the
idea should be clear)?
-- snipsnap --
[PATCH] pack-objects --all: include HEAD, which could be detached
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-pack-objects.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index cb51916..da55671 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -2219,6 +2219,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
rp_ac_alloc * sizeof(*rp_av));
}
rp_av[rp_ac++] = arg;
+ if (!strcmp("--all", arg)) {
+ ALLOC_GROW(rp_av, rp_ac + 1, rp_ac_alloc);
+ rp_av[rp_ac++] = "HEAD";
+ }
continue;
}
if (!strcmp("--thin", arg)) {
^ permalink raw reply related
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-15 14:02 UTC (permalink / raw)
To: Stephan Beyer
Cc: Sverre Rabbelier, Adeodato Simó, Johan Herland, git,
Johannes Sixt, Anders Melchiorsen, gitster
In-Reply-To: <20090115135716.GC10045@leksak.fem-net>
Hi,
On Thu, 15 Jan 2009, Stephan Beyer wrote:
> Sverre Rabbelier wrote:
> > >> editmsg?
> > >
> > > Has the same first letter as 'edit'. Would be confusing with the shortcut
> > > 'e', no?
> >
> > "msgedit" with shortcut 'm'?
>
> *sigh* If I was just not so late with sequencer...
>
> There it is "pick -e" (or "pick --edit").
... which obviously shares all the shortcomings of "edit".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Thomas Rast @ 2009-01-15 14:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901150141570.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Thomas Rast wrote:
>
> > Let git-checkout save the old branch as a symref in LAST_HEAD, and
> > make 'git checkout -' switch back to LAST_HEAD, like 'cd -' does in
> > the shell.
>
> Actually, what you want is in the reflog, no? So... parsing
> .git/logs/HEAD for the latest occurrence of "checkout: moving from " and
> then using everything up until the next space should give you the branch
> name, right?
It just feels wrong to grab that information from there; it's a
free-form comment field for user consumption. And it wasn't even that
hard to implement a LAST_HEAD.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Thomas Rast @ 2009-01-15 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901151413250.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Johannes Sixt wrote:
> > You must make sure that commits referenced by LAST_HEAD are not
> > garbage-collected. (I don't know if this happens anyway for symrefs in .git.)
>
> Note: if you used reflogs for that feature, the garbage collection could
> not have killed the commit. However, it is quite possible that the
> branch was deleted.
Suddenly I'm not so sure about either behaviour any more.
Consider:
$ git commit -m initial
[master (root-commit)]: created 812c476: "initial"
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ git checkout $(git rev-parse HEAD)
Note: moving to "812c476ca23e25efa7e4d7081153ba657a127d95" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 812c476... initial
$ git branch -D master
Deleted branch master (812c476).
$ git for-each-ref
$ git reflog expire --expire=now --all
$ git prune --expire now
$ git show
fatal: bad object HEAD
$ git show 812c476
fatal: ambiguous argument '812c476': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Oops.
Some quick RTFS shows that it indeed "only" cares about refs and
reflogs.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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