* [PATCH 03/14] Change regerror() declaration from K&R style to ANSI C (C89)
From: Marius Storm-Olsen @ 2009-09-15 13:44 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: msysgit, git, lznuaa, raa.lkml, snaury, Marius Storm-Olsen
In-Reply-To: <cover.1253021728.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
The MSVC headers typedef errcode as int, and thus confused the
compiler in the K&R style definition. ANSI style deconfuses it.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/regex/regex.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/compat/regex/regex.c b/compat/regex/regex.c
index 5ea0075..67d5c37 100644
--- a/compat/regex/regex.c
+++ b/compat/regex/regex.c
@@ -4852,11 +4852,8 @@ regexec (preg, string, nmatch, pmatch, eflags)
from either regcomp or regexec. We don't use PREG here. */
size_t
-regerror (errcode, preg, errbuf, errbuf_size)
- int errcode;
- const regex_t *preg;
- char *errbuf;
- size_t errbuf_size;
+regerror(int errcode, const regex_t *preg,
+ char *errbuf, size_t errbuf_size)
{
const char *msg;
size_t msg_size;
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 06/14] Test for WIN32 instead of __MINGW32_
From: Marius Storm-Olsen @ 2009-09-15 13:44 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: msysgit, git, lznuaa, raa.lkml, snaury, Marius Storm-Olsen
In-Reply-To: <cover.1253021728.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
The code which is conditional on MinGW32 is actually conditional on Windows.
Use the WIN32 symbol, which is defined by the MINGW32 and MSVC environments,
but not by Cygwin.
Define SNPRINTF_SIZE_CORR=1 for MSVC too, as its vsnprintf function does
not add NUL at the end of the buffer if the result fits the buffer size
exactly.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/snprintf.c | 10 ++++++----
help.c | 2 +-
| 4 ++--
run-command.c | 8 ++++----
run-command.h | 2 +-
setup.c | 2 +-
6 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/compat/snprintf.c b/compat/snprintf.c
index 4d07087..e1e0e75 100644
--- a/compat/snprintf.c
+++ b/compat/snprintf.c
@@ -2,12 +2,14 @@
/*
* The size parameter specifies the available space, i.e. includes
- * the trailing NUL byte; but Windows's vsnprintf expects the
- * number of characters to write, and does not necessarily write the
- * trailing NUL.
+ * the trailing NUL byte; but Windows's vsnprintf uses the entire
+ * buffer and avoids the trailing NUL, should the buffer be exactly
+ * big enough for the result. Defining SNPRINTF_SIZE_CORR to 1 will
+ * therefore remove 1 byte from the reported buffer size, so we
+ * always have room for a trailing NUL byte.
*/
#ifndef SNPRINTF_SIZE_CORR
-#if defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4
+#if defined(WIN32) && (!defined(__GNUC__) || __GNUC__ < 4)
#define SNPRINTF_SIZE_CORR 1
#else
#define SNPRINTF_SIZE_CORR 0
diff --git a/help.c b/help.c
index fd51b8e..e8db31f 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 __MINGW32__
+#ifdef WIN32
{ /* cannot trust the executable bit, peek into the file instead */
char buf[3] = { 0 };
int n;
--git a/pager.c b/pager.c
index f416d38..86facec 100644
--- a/pager.c
+++ b/pager.c
@@ -9,7 +9,7 @@
static int spawned_pager;
-#ifndef __MINGW32__
+#ifndef WIN32
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 __MINGW32__
+#ifndef WIN32
pager_process.preexec_cb = pager_preexec;
#endif
if (start_command(&pager_process))
diff --git a/run-command.c b/run-command.c
index bb76750..cf2d8f7 100644
--- a/run-command.c
+++ b/run-command.c
@@ -75,7 +75,7 @@ fail_pipe:
trace_argv_printf(cmd->argv, "trace: run_command:");
-#ifndef __MINGW32__
+#ifndef WIN32
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 __MINGW32__
+#ifdef WIN32
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 __MINGW32__
+#ifndef WIN32
/* 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 __MINGW32__
+#ifndef WIN32
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 0c00b25..fb34209 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 __MINGW32__
+#ifndef WIN32
pid_t pid;
#else
HANDLE tid;
diff --git a/setup.c b/setup.c
index e3781b6..029371e 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 __MINGW32__
+#ifndef WIN32
if (!pfx || !*pfx || is_absolute_path(arg))
return arg;
memcpy(path, pfx, pfx_len);
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 05/14] Fix __stdcall placement and function prototype
From: Marius Storm-Olsen @ 2009-09-15 13:44 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: msysgit, git, lznuaa, raa.lkml, snaury, Marius Storm-Olsen
In-Reply-To: <cover.1253021728.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
MSVC requires __stdcall to be between the functions return value and
the function name, and that the function pointer type is in the form
of
return_type (WINAPI *function_name)(arguments...)
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/mingw.c | 4 ++--
run-command.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 5a8fae8..34ee427 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1027,7 +1027,7 @@ static sig_handler_t timer_fn = SIG_DFL;
* length to call the signal handler.
*/
-static __stdcall unsigned ticktack(void *dummy)
+static unsigned __stdcall ticktack(void *dummy)
{
while (WaitForSingleObject(timer_event, timer_interval) == WAIT_TIMEOUT) {
if (timer_fn == SIG_DFL)
@@ -1154,7 +1154,7 @@ void mingw_open_html(const char *unixpath)
int link(const char *oldpath, const char *newpath)
{
- typedef BOOL WINAPI (*T)(const char*, const char*, LPSECURITY_ATTRIBUTES);
+ typedef BOOL (WINAPI *T)(const char*, const char*, LPSECURITY_ATTRIBUTES);
static T create_hard_link = NULL;
if (!create_hard_link) {
create_hard_link = (T) GetProcAddress(
diff --git a/run-command.c b/run-command.c
index 02aaedf..bb76750 100644
--- a/run-command.c
+++ b/run-command.c
@@ -316,7 +316,7 @@ int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const
}
#ifdef __MINGW32__
-static __stdcall unsigned run_thread(void *data)
+static unsigned __stdcall run_thread(void *data)
{
struct async *async = data;
return async->proc(async->fd_for_proc, async->data);
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 01/14] Avoid declaration after statement
From: Marius Storm-Olsen @ 2009-09-15 13:44 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: msysgit, git, lznuaa, raa.lkml, snaury, Marius Storm-Olsen
In-Reply-To: <cover.1253021728.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
MSVC does not understand this C99 style
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/mingw.c | 14 ++++++++++----
help.c | 3 ++-
run-command.c | 2 ++
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 36ef8d3..5478b74 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -123,13 +123,17 @@ int mingw_open (const char *filename, int oflags, ...)
{
va_list args;
unsigned mode;
+ int fd;
+
va_start(args, oflags);
mode = va_arg(args, int);
va_end(args);
if (!strcmp(filename, "/dev/null"))
filename = "nul";
- int fd = open(filename, oflags, mode);
+
+ fd = open(filename, oflags, mode);
+
if (fd < 0 && (oflags & O_CREAT) && errno == EACCES) {
DWORD attrs = GetFileAttributes(filename);
if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY))
@@ -580,10 +584,11 @@ static char **get_path_split(void)
static void free_path_split(char **path)
{
+ char **p = path;
+
if (!path)
return;
- char **p = path;
while (*p)
free(*p++);
free(path);
@@ -1120,9 +1125,9 @@ int sigaction(int sig, struct sigaction *in, struct sigaction *out)
#undef signal
sig_handler_t mingw_signal(int sig, sig_handler_t handler)
{
+ sig_handler_t old = timer_fn;
if (sig != SIGALRM)
return signal(sig, handler);
- sig_handler_t old = timer_fn;
timer_fn = handler;
return old;
}
@@ -1209,8 +1214,9 @@ struct dirent *mingw_readdir(DIR *dir)
if (dir->dd_handle == (long)INVALID_HANDLE_VALUE && dir->dd_stat == 0)
{
+ DWORD lasterr;
handle = FindFirstFileA(dir->dd_name, &buf);
- DWORD lasterr = GetLastError();
+ lasterr = GetLastError();
dir->dd_handle = (long)handle;
if (handle == INVALID_HANDLE_VALUE && (lasterr != ERROR_NO_MORE_FILES)) {
errno = err_win_to_posix(lasterr);
diff --git a/help.c b/help.c
index 294337e..fd51b8e 100644
--- a/help.c
+++ b/help.c
@@ -127,7 +127,7 @@ static int is_executable(const char *name)
return 0;
#ifdef __MINGW32__
- /* cannot trust the executable bit, peek into the file instead */
+{ /* cannot trust the executable bit, peek into the file instead */
char buf[3] = { 0 };
int n;
int fd = open(name, O_RDONLY);
@@ -140,6 +140,7 @@ static int is_executable(const char *name)
st.st_mode |= S_IXUSR;
close(fd);
}
+}
#endif
return st.st_mode & S_IXUSR;
}
diff --git a/run-command.c b/run-command.c
index ac314a5..02aaedf 100644
--- a/run-command.c
+++ b/run-command.c
@@ -134,6 +134,7 @@ fail_pipe:
error("cannot fork() for %s: %s", cmd->argv[0],
strerror(failed_errno = errno));
#else
+{
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
const char **sargv = cmd->argv;
char **env = environ;
@@ -197,6 +198,7 @@ fail_pipe:
dup2(s1, 1), close(s1);
if (s2 >= 0)
dup2(s2, 2), close(s2);
+}
#endif
if (cmd->pid < 0) {
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 02/14] Add define guards to compat/win32.h
From: Marius Storm-Olsen @ 2009-09-15 13:44 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: msysgit, git, lznuaa, raa.lkml, snaury, Marius Storm-Olsen
In-Reply-To: <cover.1253021728.git.mstormo@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/win32.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/compat/win32.h b/compat/win32.h
index c26384e..e8c178d 100644
--- a/compat/win32.h
+++ b/compat/win32.h
@@ -1,3 +1,6 @@
+#ifndef WIN32_H
+#define WIN32_H
+
/* common Win32 functions for MinGW and Cygwin */
#include <windows.h>
@@ -32,3 +35,5 @@ static inline int get_file_attr(const char *fname, WIN32_FILE_ATTRIBUTE_DATA *fd
return ENOENT;
}
}
+
+#endif
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [RFC/PATCH v3 00/14] Build Git with MSVC
From: Marius Storm-Olsen @ 2009-09-15 13:44 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: msysgit, git, lznuaa, raa.lkml, snaury, Marius Storm-Olsen
=== V3 2009.09.15 ===
1) Reworded patch 01: s/Microsoft Visual C++/MSVC/
2) Nuked patch 02
3) Merged patch 03 into path 08
4) Rewrote patch 06 to set _fmode instead for both MinGW and MSVC
5) Fix patch 07 to use __stdcall for thread functions instead of WINAPI
6) Rewrote patch 14 to rather use a define to _chsize
7) Fix patch 15 to use "-o $@" instead of "-o git.o"
Think that's it..
=== V2 2009.09.14 ===
Here's a second roll of the series for supporting compilation of Git
using Visual C++ (MSVC). (Sorry for the long delay on a followup, time
is in short supply these days)
There's no guarantee that the compiled result will work as well as the
current MinGW compile, or at all. However, I think it's important to
get the Git repo to a compilable state with MSVC as quickly as
possible, to further enable contributions from the Windows developers
which we are sorely lacking at the moment.
I hope that a repo which compiles successfully with the tools they are
accustomed to (also a very good debugger) will entice them to send more
patches.
In addition to this series, I have also setup a repo with binaries of
the required libs to compile Git with MSVC. Only 32bit versions for now.
So, the developer can choose to either use that, or Frank's source code
repo to build Git with MSVC. You'll find the binary repo here:
http://repo.or.cz/w/msvcgit.git
Note that the binaries will still require the msysgit environment for
execution, due to the non-binary components of Git. (Scripts, gitk,
git-gui, etc). You'll find that repo here:
http://repo.or.cz/w/msysgit.git
1) Rebased ontop on current git.git 'next'.
2) Fixed code and commit msgs based on the previous feedback.
Let me know if I forgot anything!
3) Added a proper Makefile patch for MSVC support.
You now compile with 'make MSVC=1'.
4) Added perl scripts (contrib) which uses GNU Make output to generate
MSVC IDE (.sln & .vcproj) projects and QMake projects, and picking
up the project settings from the Makefile, so it's all in one place.
5) Added necessary patches to make things compile ontop of current
'next'.
=== V1 2009.08.21 ===
So, Frank Li started this series, and I took it upon my self to help
out a bit; cleaning, reorganizing, rebasing the series. Hopefully
we're now a bit closer to including the series into mainline..
Here's a summary of what has happend:
1) This series is rebased ontop of git.git 'next', which needed an
extra patch to avoid a non-constant array creation, which
mscv doesn't like.
2) I've polished (tied to anyways) the commit messages a bit.
3) I've applied much of the feedback provided to the first round of
the patches.
4) I've split, merged and reordered some of the patches, so things
that belong together are in the same commits, and in a order of
'importance'
5) I've removed the
#define func _func
stuff, as it's not needed and Microsoft cannot really kill the
compatibility functions anyways. So, adding the define
_CRT_NONSTDC_NO_DEPRECATE
will kill the warnings seen without the defines above.
6) ..probably much more as well, but I forget..
Note: I did not sign off on the last two commits, which involve the
adding of the vcproj files, since I don't agree on adding them as is.
We need a Makefile way of compiling primarily, and second, a script
to generate the vcproj, as already discussed. But the commits are
included for completeness, at to let others compile and play with it.
I've kept the original author as is, and just signed the patches..
Thanks for watching, now bring on the comments!
Frank Li (6):
Avoid declaration after statement
Change regerror() declaration from K&R style to ANSI C (C89)
Fix __stdcall placement and function prototype
Test for WIN32 instead of __MINGW32_
Add MinGW header files to build git with MSVC
Add platform files for MSVC porting
Marius Storm-Olsen (8):
Add define guards to compat/win32.h
Set _O_BINARY as default fmode for both MinGW and MSVC
Add empty header files for MSVC port
Make usage of windows.h lean and mean
Define strncasecmp and ftruncate for MSVC
Add MSVC to Makefile
Add README for MSVC build
Add scripts to generate projects for other buildsystems (MSVC vcproj,
QMake)
.gitignore | 11 +
Makefile | 54 +++-
compat/mingw.c | 20 +-
compat/mingw.h | 9 +
compat/msvc.c | 35 ++
compat/msvc.h | 50 +++
compat/regex/regex.c | 7 +-
compat/snprintf.c | 10 +-
compat/vcbuild/README | 50 +++
compat/vcbuild/include/alloca.h | 1 +
compat/vcbuild/include/arpa/inet.h | 1 +
compat/vcbuild/include/dirent.h | 128 ++++++
compat/vcbuild/include/grp.h | 1 +
compat/vcbuild/include/inttypes.h | 1 +
compat/vcbuild/include/netdb.h | 1 +
compat/vcbuild/include/netinet/in.h | 1 +
compat/vcbuild/include/netinet/tcp.h | 1 +
compat/vcbuild/include/pwd.h | 1 +
compat/vcbuild/include/sys/ioctl.h | 1 +
compat/vcbuild/include/sys/param.h | 1 +
compat/vcbuild/include/sys/poll.h | 1 +
compat/vcbuild/include/sys/select.h | 1 +
compat/vcbuild/include/sys/socket.h | 1 +
compat/vcbuild/include/sys/time.h | 1 +
compat/vcbuild/include/sys/utime.h | 34 ++
compat/vcbuild/include/sys/wait.h | 1 +
compat/vcbuild/include/unistd.h | 92 ++++
compat/vcbuild/include/utime.h | 1 +
compat/vcbuild/scripts/clink.pl | 48 +++
compat/vcbuild/scripts/lib.pl | 26 ++
compat/win32.h | 7 +
compat/winansi.c | 1 -
contrib/buildsystems/Generators.pm | 42 ++
contrib/buildsystems/Generators/QMake.pm | 189 +++++++++
contrib/buildsystems/Generators/Vcproj.pm | 639 +++++++++++++++++++++++++++++
contrib/buildsystems/engine.pl | 353 ++++++++++++++++
contrib/buildsystems/generate | 29 ++
contrib/buildsystems/parse.pl | 228 ++++++++++
git-compat-util.h | 9 +
help.c | 5 +-
pager.c | 4 +-
run-command.c | 12 +-
run-command.h | 2 +-
setup.c | 2 +-
thread-utils.c | 5 +-
45 files changed, 2084 insertions(+), 33 deletions(-)
create mode 100644 compat/msvc.c
create mode 100644 compat/msvc.h
create mode 100644 compat/vcbuild/README
create mode 100644 compat/vcbuild/include/alloca.h
create mode 100644 compat/vcbuild/include/arpa/inet.h
create mode 100644 compat/vcbuild/include/dirent.h
create mode 100644 compat/vcbuild/include/grp.h
create mode 100644 compat/vcbuild/include/inttypes.h
create mode 100644 compat/vcbuild/include/netdb.h
create mode 100644 compat/vcbuild/include/netinet/in.h
create mode 100644 compat/vcbuild/include/netinet/tcp.h
create mode 100644 compat/vcbuild/include/pwd.h
create mode 100644 compat/vcbuild/include/sys/ioctl.h
create mode 100644 compat/vcbuild/include/sys/param.h
create mode 100644 compat/vcbuild/include/sys/poll.h
create mode 100644 compat/vcbuild/include/sys/select.h
create mode 100644 compat/vcbuild/include/sys/socket.h
create mode 100644 compat/vcbuild/include/sys/time.h
create mode 100644 compat/vcbuild/include/sys/utime.h
create mode 100644 compat/vcbuild/include/sys/wait.h
create mode 100644 compat/vcbuild/include/unistd.h
create mode 100644 compat/vcbuild/include/utime.h
create mode 100644 compat/vcbuild/scripts/clink.pl
create mode 100644 compat/vcbuild/scripts/lib.pl
create mode 100644 contrib/buildsystems/Generators.pm
create mode 100644 contrib/buildsystems/Generators/QMake.pm
create mode 100644 contrib/buildsystems/Generators/Vcproj.pm
create mode 100644 contrib/buildsystems/engine.pl
create mode 100644 contrib/buildsystems/generate
create mode 100644 contrib/buildsystems/parse.pl
^ permalink raw reply
* Re: Commited to wrong branch
From: Howard Miller @ 2009-09-15 13:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <26ae428a0909150558i508e5878q8a1ee7cb7311fc57@mail.gmail.com>
What's to stop me.........
* The "wrong" branch just tracks a remote so I can just dump it once I
have this fixed - (delete it and recreate it?)
* after my 'reset' the files I have in my working copy (still the
wrong branch) should be the latest version ('git reset' does not
change the working copy I think?)
* So can I grab these files (they are mostly new), checkout the
correct version, and just overwrite the existing files? I'll loose
some history but not much and I don't care
Seems too easy :-)
2009/9/15 Howard Miller <howard@e-learndesign.co.uk>:
> Martin,
>
> Got as far as applying the temporary patch and I now get a load of...
>
> Reversed (or previously applied) patch detected! Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file
> theme/onepointnine/local.css.rej
> The next patch would create the file theme/onepointnine/local.css,
>
> funnily I didn't think that file had anything to do with it, but when
> I changed branched I got
>
> T theme/onepointnine/local.css
>
> Not sure what the T means :-(
>
> H.
>
> 2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
>> On Tue, Sep 15, 2009 at 2:10 PM, Howard Miller
>> <howard@e-learndesign.co.uk> wrote:
>>> Martin,
>>>
>>> Looked at gitk - yes there is definitely one more commit still on the
>>> current (wrong) branch.
>>>
>>> I deleted the offending file and have now successfully switched to the
>>> other (correct) branch.
>>
>> ok!
>>
>> so you have
>>
>> A - The commit you undid, and have in the temp patch. Note that this
>> patch file is missing the file you've rm'd.
>>
>> B - A commit you haven't "undone" on the "wrong" branch X.
>>
>> and you are on branch Y
>>
>> so now...
>>
>> 1 - git format-patch Y^..Y # will export that patch B into a file for you.
>> 2 - git am 0001-whatever-the-name-of-the-file.txt # patch B
>> this may need conflict resolution - read the notes it prints! If
>> it refuses to apply the patch, do "git am --skip" to indicate you
>> won't use git-am no more for this, and try applying it with the patch
>> utility.
>> 3 - patch -p1 < your-patch-A.patch
>> 4 - find and readd the file you rm'd earlier -- if you don't have
>> another copy, we can get it from git reflog but that'll take extra
>> steps :-)
>> 5 - git commit # you're committing your patch A here
>>
>> Now, review with gitk to see that you have what you want to have
>> there. If it's all ok...
>>
>> 6 - git checkout X
>> 7 - git reset --hard # unstich that last stray commit
>> --
>>
>> hope the above helps. Git pros will see that the process could be much
>> shorter :-) I chose this specific path because in exporting your
>> patches and applying them again you can see each step.
>>
>> If we were to start again, and the branches are reasonably close to
>> eachother (not 19_STABLE vs cvshead :-) ) then you can say
>>
>> - X has 2 bad commits that belong to Y, then
>> 1 - gitk X & # open gitk to visualise the commits, send it to the background
>> 2 - git checkout Y
>> 3 - git cherry-pick X^ # takes the next-to-last commit from X and
>> tries to apply it here - conflict resolution may be needed
>> 4 - git cherry-pick X # same with the very last commit on X
>> 5 - gitk # check that is all as you want it
>> 6 - git checkout X
>> 7 - git reset --hard X^^ # "rewind 2 commits"
>>
>> hth,
>>
>>
>>
>> m
>> --
>> martin.langhoff@gmail.com
>> martin@laptop.org -- School Server Architect
>> - ask interesting questions
>> - don't get distracted with shiny stuff - working code first
>> - http://wiki.laptop.org/go/User:Martinlanghoff
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* 'git stash apply' in dirty working directory
From: Daniel Trstenjak @ 2009-09-15 13:05 UTC (permalink / raw)
To: git
Hi all,
isn't the stash for fumbling around with my working directory?
So why I shouldn't be able to apply the stash to a dirty working directory?
I'm not even a fan of not being able to pull in a dirty working
directory. There might be some arguments for it, but most of them
boil down that you better should know what you're doing.
But not being able to apply the stash to a dirty working directory?
Come on!
Greetings,
Daniel
--
Daniel Trstenjak Tel : +49 (0)7071-9457-264
science + computing ag FAX : +49 (0)7071-9457-511
Hagellocher Weg 73 mailto: Daniel.Trstenjak@science-computing.de
D-72070 Tübingen WWW : http://www.science-computing.de/
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
^ permalink raw reply
* Re: Commited to wrong branch
From: Howard Miller @ 2009-09-15 13:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Martin Langhoff, git
In-Reply-To: <20090915130640.GC31846@atjola.homenet>
Please stop what?
Ok... thanks for all your help guys but I'm giving up. A silly mistake
has wasted a day. It shouldn't be like that. I appreciate that it's me
that doesn't know enough about the way git works but I don't want to
know. I don't have time - I have actual work to do. It'll be quicker
to recreate the code I have lost.
Git encourages one to be experimental and create branches and stuff
all the time which is great but doesn't do enough to stop one getting
completely confused. That's how it feels to me anyway. Yes I am in a
sulk - sorry :-)
Howard
2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
> [Please stop top-posting...]
>
> On 2009.09.15 13:58:32 +0100, Howard Miller wrote:
>> Got as far as applying the temporary patch and I now get a load of...
>>
>> Reversed (or previously applied) patch detected! Assume -R? [n]
>> Apply anyway? [n]
>> Skipping patch.
>> 1 out of 1 hunk ignored -- saving rejects to file
>> theme/onepointnine/local.css.rej
>> The next patch would create the file theme/onepointnine/local.css,
>
> Just don't use patch(1), there's no sane reason to do that, you're
> sacrificing all of what git can offer there.
>
> cherry-pick or format-patch + am -3 are simply much better. (Or
> "checkout -m" or stash + stash apply, if you're dealing with uncommitted
> changes).
>
> Björn
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Commited to wrong branch
From: Björn Steinbrink @ 2009-09-15 13:06 UTC (permalink / raw)
To: Howard Miller; +Cc: Martin Langhoff, git
In-Reply-To: <26ae428a0909150558i508e5878q8a1ee7cb7311fc57@mail.gmail.com>
[Please stop top-posting...]
On 2009.09.15 13:58:32 +0100, Howard Miller wrote:
> Got as far as applying the temporary patch and I now get a load of...
>
> Reversed (or previously applied) patch detected! Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file
> theme/onepointnine/local.css.rej
> The next patch would create the file theme/onepointnine/local.css,
Just don't use patch(1), there's no sane reason to do that, you're
sacrificing all of what git can offer there.
cherry-pick or format-patch + am -3 are simply much better. (Or
"checkout -m" or stash + stash apply, if you're dealing with uncommitted
changes).
Björn
^ permalink raw reply
* Re: [PATCH 1/2] Work around leftover temporary save file.
From: Alex Riesen @ 2009-09-15 13:01 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Alexy Borzenkov, Paul Mackerras
In-Reply-To: <87ab0wcsyp.fsf@users.sourceforge.net>
On Tue, Sep 15, 2009 at 11:26, Pat Thoyts
<patthoyts@users.sourceforge.net> wrote:
>
> If a file exists and is hidden on Windows the Tcl open command will
> fail as the attributes provided in the CREAT call fail to match those
> of the existing file. Forcing removal of the temporary file before we
> begin solves any problems caused by previous failures to save the
> application settings. An alternative would be to remove the hidden
> attribute before calling 'open'.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
> ---
> gitk | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/gitk b/gitk
> index 1306178..a0214b7 100755
> --- a/gitk
> +++ b/gitk
> @@ -2526,6 +2526,7 @@ proc savestuff {w} {
> if {$stuffsaved} return
> if {![winfo viewable .]} return
> catch {
> + if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
maybe another gitk instance is writing it at exactly same moment
in time? Writing is known to take a few moments. Especially on Windows.
^ permalink raw reply
* Re: Commited to wrong branch
From: Howard Miller @ 2009-09-15 12:58 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90909150546i508d3781id1dcd8e6c64942cf@mail.gmail.com>
Martin,
Got as far as applying the temporary patch and I now get a load of...
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
theme/onepointnine/local.css.rej
The next patch would create the file theme/onepointnine/local.css,
funnily I didn't think that file had anything to do with it, but when
I changed branched I got
T theme/onepointnine/local.css
Not sure what the T means :-(
H.
2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
> On Tue, Sep 15, 2009 at 2:10 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> Martin,
>>
>> Looked at gitk - yes there is definitely one more commit still on the
>> current (wrong) branch.
>>
>> I deleted the offending file and have now successfully switched to the
>> other (correct) branch.
>
> ok!
>
> so you have
>
> A - The commit you undid, and have in the temp patch. Note that this
> patch file is missing the file you've rm'd.
>
> B - A commit you haven't "undone" on the "wrong" branch X.
>
> and you are on branch Y
>
> so now...
>
> 1 - git format-patch Y^..Y # will export that patch B into a file for you.
> 2 - git am 0001-whatever-the-name-of-the-file.txt # patch B
> this may need conflict resolution - read the notes it prints! If
> it refuses to apply the patch, do "git am --skip" to indicate you
> won't use git-am no more for this, and try applying it with the patch
> utility.
> 3 - patch -p1 < your-patch-A.patch
> 4 - find and readd the file you rm'd earlier -- if you don't have
> another copy, we can get it from git reflog but that'll take extra
> steps :-)
> 5 - git commit # you're committing your patch A here
>
> Now, review with gitk to see that you have what you want to have
> there. If it's all ok...
>
> 6 - git checkout X
> 7 - git reset --hard # unstich that last stray commit
> --
>
> hope the above helps. Git pros will see that the process could be much
> shorter :-) I chose this specific path because in exporting your
> patches and applying them again you can see each step.
>
> If we were to start again, and the branches are reasonably close to
> eachother (not 19_STABLE vs cvshead :-) ) then you can say
>
> - X has 2 bad commits that belong to Y, then
> 1 - gitk X & # open gitk to visualise the commits, send it to the background
> 2 - git checkout Y
> 3 - git cherry-pick X^ # takes the next-to-last commit from X and
> tries to apply it here - conflict resolution may be needed
> 4 - git cherry-pick X # same with the very last commit on X
> 5 - gitk # check that is all as you want it
> 6 - git checkout X
> 7 - git reset --hard X^^ # "rewind 2 commits"
>
> hth,
>
>
>
> m
> --
> martin.langhoff@gmail.com
> martin@laptop.org -- School Server Architect
> - ask interesting questions
> - don't get distracted with shiny stuff - working code first
> - http://wiki.laptop.org/go/User:Martinlanghoff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] gitk: restore wm state to normal before saving geometry information
From: Alexey Borzenkov @ 2009-09-15 12:54 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <87eiq8ct40.fsf@users.sourceforge.net>
On Tue, Sep 15, 2009 at 4:03 PM, Pat Thoyts
<patthoyts@users.sourceforge.net> wrote:
>>gitk now includes patches for saving and restoring wm state, however
>>because it saves wm geometry when window can still be maximized the
>>maximize/restore button becomes useless after restarting gitk (you
>>will get a huge displaced window if you try to restore it). This
>>patch fixes this issue by storing window geometry in normal state.
> I tried this patch on windows and I find that it causes the columns in
> the top view to creep each time you restart the application. This is I
> think due to the way this patch sets the state to normal before
> recording all the settings.
This is strange, as I certainly don't see this behaviour now (I'm
using gitk in version 1.6.4.3). Actually, I did see that behaviour
once, but I believe this was when I ran an unpatched gitk which seemed
to record wrong geometry. As soon as I cleared ~/.gitk of those wrong
coordinates I haven't seen this behaviour anymore.
On the other hand, when I resize columns and then maximize/restore the
window repeatedly I see that their sizes change in a strange way (and
the smaller restored window they stranger are results) until hitting
some sort of equilibrium, then maximize/restore doesn't have effect on
their sizes anymore. So maybe there's a bug not in a way my patch
restores the window, but in a way window resizes are handled.
> I will post an alternative patch that records the normal geometry
> whenever it changes instead which seems to work better for me.
By all means.
^ permalink raw reply
* Re: Commited to wrong branch
From: Martin Langhoff @ 2009-09-15 12:46 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0909150510n56b1d4eg6565a6cca8c9b46c@mail.gmail.com>
On Tue, Sep 15, 2009 at 2:10 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> Martin,
>
> Looked at gitk - yes there is definitely one more commit still on the
> current (wrong) branch.
>
> I deleted the offending file and have now successfully switched to the
> other (correct) branch.
ok!
so you have
A - The commit you undid, and have in the temp patch. Note that this
patch file is missing the file you've rm'd.
B - A commit you haven't "undone" on the "wrong" branch X.
and you are on branch Y
so now...
1 - git format-patch Y^..Y # will export that patch B into a file for you.
2 - git am 0001-whatever-the-name-of-the-file.txt # patch B
this may need conflict resolution - read the notes it prints! If
it refuses to apply the patch, do "git am --skip" to indicate you
won't use git-am no more for this, and try applying it with the patch
utility.
3 - patch -p1 < your-patch-A.patch
4 - find and readd the file you rm'd earlier -- if you don't have
another copy, we can get it from git reflog but that'll take extra
steps :-)
5 - git commit # you're committing your patch A here
Now, review with gitk to see that you have what you want to have
there. If it's all ok...
6 - git checkout X
7 - git reset --hard # unstich that last stray commit
--
hope the above helps. Git pros will see that the process could be much
shorter :-) I chose this specific path because in exporting your
patches and applying them again you can see each step.
If we were to start again, and the branches are reasonably close to
eachother (not 19_STABLE vs cvshead :-) ) then you can say
- X has 2 bad commits that belong to Y, then
1 - gitk X & # open gitk to visualise the commits, send it to the background
2 - git checkout Y
3 - git cherry-pick X^ # takes the next-to-last commit from X and
tries to apply it here - conflict resolution may be needed
4 - git cherry-pick X # same with the very last commit on X
5 - gitk # check that is all as you want it
6 - git checkout X
7 - git reset --hard X^^ # "rewind 2 commits"
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* put in scripts
From: Michael.Kraemer @ 2009-09-15 12:16 UTC (permalink / raw)
To: git
hello,
How i can put in this script in GIT?
(http://git.or.cz/gitwiki/ExampleScripts#Settingthetimestampsofthefilestothecommittimestampofthecommitwhichlasttouchedthem
)
I need the "last commit time" function like in SVN.
THANKS
EISENMANN AG
i.A. Michael Krämer
Postfach 1280 - 71002 Böblingen
Tübinger Straße 81 - 71032 Böblingen
E-Mail: Michael.Kraemer@eisenmann.com
Internet: http://www.eisenmann.com
_________________________________________________________________________
Sitz: Böblingen, AG Stuttgart HRB 245891
USt.-IdNr.: DE 145 141 533
Vorstand: Dr. Matthias von Krauland (Sprecher), Dr. Thomas Beck, Dr.
Kersten Christoph Link
Vorsitzender des Aufsichtsrates: Peter Eisenmann
Diese E-Mail sowie etwaige Anlagen sind ausschließlich für den Adressaten
bestimmt und können vertrauliche oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Empfänger sind,
unterrichten Sie bitte den Absender und vernichten Sie diese Mail.
Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese
E-Mail zu speichern, weiterzuleiten oder ihren Inhalt, auf welche Weise
auch immer, zu verwenden. Wir verwenden aktuelle Virenschutzprogramme.
Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte, mit
Viren befallene E-Mails entstehen, schließen wir jede Haftung aus.
The information contained in this e-mail or attachments is intended only
for its addressee and may contain confidential and/or privileged
information. If you have received this e-mail in error, please notify
the sender and delete the e-mail. If you are not the intended recipient,
you are hereby notified, that saving, distribution or use of the
content of this e-mail in any way is prohibited. We use updated virus
protection software. We do not accept any responsibility for damages
caused anyhow by viruses transmitted via e-mail.
^ permalink raw reply
* Re: Commited to wrong branch
From: Howard Miller @ 2009-09-15 12:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90909150416h60ea7d74xd2337fe50f603dcb@mail.gmail.com>
Martin,
Looked at gitk - yes there is definitely one more commit still on the
current (wrong) branch.
I deleted the offending file and have now successfully switched to the
other (correct) branch.
Howard
2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
> On Tue, Sep 15, 2009 at 1:05 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> I'm pretty shocked how difficult this is... still...
>
> No prob. It's only hard at the beginning :-)
>
>> I'm finding git logs and reflogs pretty difficult to read and
>> interpret (head melting) - in particular telling what happened on what
>> branch -
>
> I found gitk enormously helpful to visualise things. Try
>
> gitk # will show you the current branch
>
> gitk X Y # will show you both branches
>
> gitk is a ton easier to visualise. git log is pretty good but won't
> show merges, so it's limited.
>
> git reflog is confusing, but it's mostly a tool to help when there's
> been a mess and you want to diagnose WTH happened...
>
>>but looking at the reflog (which I assume is showing me the
>> actions on the current branch, but I'm not sure)
>
> Don't worry about the reflog...
>
>> I think I must have
>> made two commits on the wrong branch so the reset has only 'popped'
>> the top one. Other than that your interpretation is correct.
>
> Ok, so looking at gitk, there would still be one "wrong" commit. Can
> you confirm?
>
>> I cannot currently change branches - it only complains about one file.
>
> If you did follow my previous instructions (specially doing 'git reset
> --hard'), then this should not happen. Except...
>
> Except when you have a file that git is not tracking, and it exists in
> the "other" branch. The commit you undid earlier probably added that
> file. So just rm that file, and change branches.
>
>> I'm a bit worried about that - I would like to understand why this is
>> a problem but I don't.
>
> About the file? It was "new" in the commit you un-committed. So when
> you do git reset --hard, git makes sure all the files it is
> _currently_ tracking are "unchanged". If that file was new, it ignores
> it. Just rm it and be happy.
>
>> So I am now a little hazy on how to deal with previous TWO commits.
>
> Just review gitk and confirm if there are more commits to unstich --
> and we'll work from there
>
>
> m
> --
> martin.langhoff@gmail.com
> martin@laptop.org -- School Server Architect
> - ask interesting questions
> - don't get distracted with shiny stuff - working code first
> - http://wiki.laptop.org/go/User:Martinlanghoff
>
^ permalink raw reply
* [PATCH 2/2] Fix the geometry when restoring from zoomed state.
From: Pat Thoyts @ 2009-09-15 9:37 UTC (permalink / raw)
To: git; +Cc: Alexy Borzenkov, Paul Mackerras
In-Reply-To: <1252437756-81986-1-git-send-email-snaury@gmail.com>
The patch to handle the geometry of a restored gitk by Alexy Borzenkov
causes the position of the columns to creep each time the application
is restarted. This patch addresses this by remembering the application
geometry for the normal state and saving that regardless of the actual
state when the application is closed.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
gitk | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index a0214b7..67122c3 100755
--- a/gitk
+++ b/gitk
@@ -2251,6 +2251,8 @@ proc makewindow {} {
}
wm geometry . "${w}x$h"
}
+ } else {
+ set geometry(main) [wm geometry .]
}
if {[info exists geometry(state)] && $geometry(state) eq "zoomed"} {
@@ -2265,6 +2267,11 @@ proc makewindow {} {
set ::BM "2"
}
+ bind . <Configure> {
+ if {[winfo toplevel %W] eq "%W" && [wm state %W] eq "normal"} {
+ set ::geometry(main) %wx%h+%x+%y
+ }
+ }
bind .pwbottom <Configure> {resizecdetpanes %W %w}
pack .ctop -fill both -expand 1
bindall <1> {selcanvline %W %x %y}
@@ -2556,7 +2563,7 @@ proc savestuff {w} {
puts $f [list set extdifftool $extdifftool]
puts $f [list set perfile_attrs $perfile_attrs]
- puts $f "set geometry(main) [wm geometry .]"
+ puts $f "set geometry(main) $::geometry(main)"
puts $f "set geometry(state) [wm state .]"
puts $f "set geometry(topwidth) [winfo width .tf]"
puts $f "set geometry(topheight) [winfo height .tf]"
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH 1/2] Work around leftover temporary save file.
From: Pat Thoyts @ 2009-09-15 9:26 UTC (permalink / raw)
To: git; +Cc: Alexy Borzenkov, Paul Mackerras
In-Reply-To: <1252437756-81986-1-git-send-email-snaury@gmail.com>
If a file exists and is hidden on Windows the Tcl open command will
fail as the attributes provided in the CREAT call fail to match those
of the existing file. Forcing removal of the temporary file before we
begin solves any problems caused by previous failures to save the
application settings. An alternative would be to remove the hidden
attribute before calling 'open'.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 1306178..a0214b7 100755
--- a/gitk
+++ b/gitk
@@ -2526,6 +2526,7 @@ proc savestuff {w} {
if {$stuffsaved} return
if {![winfo viewable .]} return
catch {
+ if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
set f [open "~/.gitk-new" w]
if {$::tcl_platform(platform) eq {windows}} {
file attributes "~/.gitk-new" -hidden true
--
1.6.4.msysgit.0
^ permalink raw reply related
* Re: Patches for git-push --confirm and --show-subjects
From: Owen Taylor @ 2009-09-15 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7v1vm892ow.fsf@alter.siamese.dyndns.org>
On Mon, 2009-09-14 at 22:50 -0700, Junio C Hamano wrote:
> You might not see a "policy" in your approach, but it makes some troubling
> hardcoded policy decisions. Here are a few examples of what your patch
> decides, and makes it harder for other people to build on (rather, "around):
>
> - We support only interactive validation (confirmation). If you want to
> have an unattended validation scheme, there is no way to enhance the
> mechanism this patch adds to do so. You instead need to add yet
> another command line option and hook into the same place as this patch
> touches.
It seems like the bulk of any patch is going to be creating a clean
position in the code to do confirmation.
> - We assume "git push" is run from terminal, and the only kind of
> interactive validation we support is via typed confirmation from a line
> terminal "[Y/n]?" If you want to run "git push" from a GUI frontend
> and have the user interact with a dialog window popped up separately,
> you are also out of luck.
That's an interesting situation to consider. How do you see a pre-push
hook being used for that?
> - We assume it is good enough to have various built-in presentations of
> supporting information while asking for confirmations; there is no way
> for casual end users to customize and enhance it.
A shell script that duplicates the display logic from transport.c while
interleaving nicely abbreviated bits of log will be on the complex side.
Is forking and modifying such a script going to be approachable for
casual end users?
- Owen
^ permalink raw reply
* Re: Question about git-svn
From: Martin Larsson @ 2009-09-15 11:49 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090905060940.GB22272@dcvr.yhbt.net>
On Fri, 2009-09-04 at 23:09 -0700, Eric Wong wrote:
> martin liste larsson <martin.liste.larsson@gmail.com> wrote:
> > I have a problem using git-svn. Is this the right place to ask then?
>
> Hi, Yes, feel free to Cc me directly as well.
Sorry for the long delay, your answer seemed to get lost in the
flood... :*)
> Just checking the obvious, you are running "git svn fetch", right?
It seemed the download terminated, for some reason. Running "git svn
fetch" again allowed it to continue. After a couple of days and
attempts, everything got downloaded. But it would be helpful if git told
me it had failed. As it was now, the end of a failed run looked like
this (a random selection):
...
r495 = da7253aa4d2af7d3349b36d917573e948ccd2828 (tags/DelfiRaadgiver-2.6.0-b9@1352)
A Kildekode/Script.deploy/deploy_all_webapps_utv.cmd
r496 = 28e21ba0098d7f7ae74f134af42fe8dc92718f56 (tags/DelfiRaadgiver-2.6.0-b9@1352)
M Kildekode/Database/data/kundespesifikk/fanasb/data_dr_aktivaklasser.sql
r497 = 58543e617e27bb7960e0b64ab2419edd90b5c56e (tags/DelfiRaadgiver-2.6.0-b9@1352)
M Kildekode/Moduler/DRBasis/src/java/no/delfidata/raad2/jdbo/func/RaadJDBOOpsImpl.java
r498 = e882fe24795addf8cecdeea9dcb82f1a49697e40 (tags/DelfiRaadgiver-2.6.0-b9@1352)
M Kildekode/Database/data/kundespesifikk/fanasb/data_ds_user.sql
r499 = e8f6b1350d2d6fcd7fe786f1aa4837e1f61cf8b3 (tags/DelfiRaadgiver-2.6.0-b9@1352)
M Kildekode/Database/dokumentasjon/raad_db_1_1.PDM
r500 = cd273927d38ed673c2ec895f641f322dc8818f9a (tags/DelfiRaadgiver-2.6.0-b9@1352)
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Counting objects: 36, done.
Compressing objects: 100% (34/34), done.
Writing objects: 100% (36/36), done.
Total 36 (delta 10), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
M Kildekode/Database/data/kundespesifikk/handelsbanken/data_ds_user.sql
r501 = 27fc97c162b9cf440ce8a5f6e8dea10354324309 (tags/DelfiRaadgiver-2.6.0-b9@1352)
M Kildekode/Database/data/kundespesifikk/sbm/data_dr_aktivaklasser.sql
r502 = 19d5cf2da05f7b92cb134c6ae83f6ffc5f3cde08 (tags/DelfiRaadgiver-2.6.0-b9@1352)
M Kildekode/Database/data/kundespesifikk/sbsoer/data_dr_aktivaklasser.sql
M Kildekode/Database/data/kundespesifikk/sbsoer/data_dr_aktivaklasser.xls
r503 = f73d7bb66e7bfe6a05647da371be477bf43d36e5 (tags/DelfiRaadgiver-2.6.0-b9@1352)
A Kildekode/Database/data/kundespesifikk/sdc/data_ds_user.sql
r504 = 8fdf43287207b4029679e4e86c405eabd2be6596 (tags/DelfiRaadgiver-2.6.0-b9@1352)
A Kildekode/Script.deploy/build_all_webapps_utv.xml
M Kildekode/Script.deploy/deploy_all_webapps_utv.cmd
r505 = d7a31939c0aed653540b471c8f5e464870fca5b1 (tags/DelfiRaadgiver-2.6.0-b9@1352)
M Kildekode/Script.deploy/build_all_webapps_utv.xml
r506 = 4ff67d714dedeed065c359376b7d055d67a4c02b (tags/DelfiRaadgiver-2.6.0-b9@1352)
martin@martin:~/Arbeid/git-rpm$
There's no real indication that this failed. But "git branch -a" doesn't
list 'master'.
However, as I said, repeating "git svn fetch" until very tired, made it
finally work...
M.
^ permalink raw reply
* Re: Commited to wrong branch
From: Björn Steinbrink @ 2009-09-15 11:19 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Howard Miller, git
In-Reply-To: <46a038f90909150355h20b39c71w4af7e2be2920fdbb@mail.gmail.com>
On 2009.09.15 12:55:58 +0200, Martin Langhoff wrote:
> On Tue, Sep 15, 2009 at 12:31 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
> > I am resurrecting a discussion from a week or two back (been on
> > holiday). As follows...
> >
> > I had made some changes to some files and then done a commit. Only
> > then did I realise that I had the wrong branch checked out. To make
> > matters worse I then did a 'git reset HEAD^' which means that I can
> > now no longer switch branches. I am stuck. I had some advice (thanks!)
> > but it was not complete. I'd appreciate some more help.
>
> Hi Howard,
>
> just to make sure I understand your issue
>
> 1 - you were on branch X, thinking your were on branch Y
> 2 - edit, diff, commit, realised the mistake
> 3 - git reset HEAD^
>
> so if you now run `git status` and `git diff` it will show your
> changes as if they were uncommitted and unstaged.
Not "as if", they are.
> (Before you start with various attempts to recover below, a great
> trick is to make an instant-backup in case things go wrong: cd .. / ;
> cp -pr moodle.git moodle-backup.git ; cd moodle.git )
>
> You can now try do do
>
> 4 - git checkout Y
>
> and if the changes are on files that don't change between X and Y,
> then git will change the branches and keep your changes there. If the
> files are different between X and Y, it won't work.
Well, then you could use "git checkout -m Y", to have git try a
three-way merge (which might of course leave conflicts).
> What I can recommend is to save your patch, as follows
>
> 5 - git diff > tempchanges.patch
> 6 - git reset --hard # this will discard your changes, careful
> 7 - git checkout Y
> 8 - patch -p1 < tempchanges.patch
>
> The patch may not apply cleanly :-) -- note that patch is more
> tolerant of iffy merges than git's internal implementation ("git
> apply") -- so it will succeed more often... but the results need
> review.
But a lot worse than the usual 3-way merge stuff, like "checkout -m" or
"stash apply". The advantage of "stash" + "stash apply" is that, in case
of conflicts, you can easily retry to fix them over and over again,
while with "checkout -m", you can't easily start over AFAIK.
> There is a more git-style approach that is to use git-stash -- it uses
> git-apply and may not do what you want.
Only "stash apply --index" uses "git apply", and only to re-apply the
staged changes. The changes for the working tree are applied using a
3way merge.
Björn
^ permalink raw reply
* Re: Commited to wrong branch
From: Martin Langhoff @ 2009-09-15 11:16 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0909150405v3087016fxee5ac98057868677@mail.gmail.com>
On Tue, Sep 15, 2009 at 1:05 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> I'm pretty shocked how difficult this is... still...
No prob. It's only hard at the beginning :-)
> I'm finding git logs and reflogs pretty difficult to read and
> interpret (head melting) - in particular telling what happened on what
> branch -
I found gitk enormously helpful to visualise things. Try
gitk # will show you the current branch
gitk X Y # will show you both branches
gitk is a ton easier to visualise. git log is pretty good but won't
show merges, so it's limited.
git reflog is confusing, but it's mostly a tool to help when there's
been a mess and you want to diagnose WTH happened...
>but looking at the reflog (which I assume is showing me the
> actions on the current branch, but I'm not sure)
Don't worry about the reflog...
> I think I must have
> made two commits on the wrong branch so the reset has only 'popped'
> the top one. Other than that your interpretation is correct.
Ok, so looking at gitk, there would still be one "wrong" commit. Can
you confirm?
> I cannot currently change branches - it only complains about one file.
If you did follow my previous instructions (specially doing 'git reset
--hard'), then this should not happen. Except...
Except when you have a file that git is not tracking, and it exists in
the "other" branch. The commit you undid earlier probably added that
file. So just rm that file, and change branches.
> I'm a bit worried about that - I would like to understand why this is
> a problem but I don't.
About the file? It was "new" in the commit you un-committed. So when
you do git reset --hard, git makes sure all the files it is
_currently_ tracking are "unchanged". If that file was new, it ignores
it. Just rm it and be happy.
> So I am now a little hazy on how to deal with previous TWO commits.
Just review gitk and confirm if there are more commits to unstich --
and we'll work from there
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Commited to wrong branch
From: Howard Miller @ 2009-09-15 11:05 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90909150355h20b39c71w4af7e2be2920fdbb@mail.gmail.com>
Hi Martin,
I'm pretty shocked how difficult this is... still...
I'm finding git logs and reflogs pretty difficult to read and
interpret (head melting) - in particular telling what happened on what
branch - but looking at the reflog (which I assume is showing me the
actions on the current branch, but I'm not sure) I think I must have
made two commits on the wrong branch so the reset has only 'popped'
the top one. Other than that your interpretation is correct.
I cannot currently change branches - it only complains about one file.
I'm a bit worried about that - I would like to understand why this is
a problem but I don't.
So I am now a little hazy on how to deal with previous TWO commits.
Sorry for misery.... I've lost the plot a bit here :-)
Howard
2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
> On Tue, Sep 15, 2009 at 12:31 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> I am resurrecting a discussion from a week or two back (been on
>> holiday). As follows...
>>
>> I had made some changes to some files and then done a commit. Only
>> then did I realise that I had the wrong branch checked out. To make
>> matters worse I then did a 'git reset HEAD^' which means that I can
>> now no longer switch branches. I am stuck. I had some advice (thanks!)
>> but it was not complete. I'd appreciate some more help.
>
> Hi Howard,
>
> just to make sure I understand your issue
>
> 1 - you were on branch X, thinking your were on branch Y
> 2 - edit, diff, commit, realised the mistake
> 3 - git reset HEAD^
>
> so if you now run `git status` and `git diff` it will show your
> changes as if they were uncommitted and unstaged.
>
> (Before you start with various attempts to recover below, a great
> trick is to make an instant-backup in case things go wrong: cd .. / ;
> cp -pr moodle.git moodle-backup.git ; cd moodle.git )
>
> You can now try do do
>
> 4 - git checkout Y
>
> and if the changes are on files that don't change between X and Y,
> then git will change the branches and keep your changes there. If the
> files are different between X and Y, it won't work.
>
> What I can recommend is to save your patch, as follows
>
> 5 - git diff > tempchanges.patch
> 6 - git reset --hard # this will discard your changes, careful
> 7 - git checkout Y
> 8 - patch -p1 < tempchanges.patch
>
> The patch may not apply cleanly :-) -- note that patch is more
> tolerant of iffy merges than git's internal implementation ("git
> apply") -- so it will succeed more often... but the results need
> review.
>
> There is a more git-style approach that is to use git-stash -- it uses
> git-apply and may not do what you want. The steps are
>
> 5a - git stash # will save your changed files into a "stashed commit"
> and clear out the changes from your working copy
> 6a - git checkout Y
> 7a - git stash apply
>
> hth,
>
>
>
> m
> --
> martin.langhoff@gmail.com
> martin@laptop.org -- School Server Architect
> - ask interesting questions
> - don't get distracted with shiny stuff - working code first
> - http://wiki.laptop.org/go/User:Martinlanghoff
>
^ permalink raw reply
* Re: Commited to wrong branch
From: Martin Langhoff @ 2009-09-15 10:55 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0909150331q391ed39ak622902d175b46d84@mail.gmail.com>
On Tue, Sep 15, 2009 at 12:31 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> I am resurrecting a discussion from a week or two back (been on
> holiday). As follows...
>
> I had made some changes to some files and then done a commit. Only
> then did I realise that I had the wrong branch checked out. To make
> matters worse I then did a 'git reset HEAD^' which means that I can
> now no longer switch branches. I am stuck. I had some advice (thanks!)
> but it was not complete. I'd appreciate some more help.
Hi Howard,
just to make sure I understand your issue
1 - you were on branch X, thinking your were on branch Y
2 - edit, diff, commit, realised the mistake
3 - git reset HEAD^
so if you now run `git status` and `git diff` it will show your
changes as if they were uncommitted and unstaged.
(Before you start with various attempts to recover below, a great
trick is to make an instant-backup in case things go wrong: cd .. / ;
cp -pr moodle.git moodle-backup.git ; cd moodle.git )
You can now try do do
4 - git checkout Y
and if the changes are on files that don't change between X and Y,
then git will change the branches and keep your changes there. If the
files are different between X and Y, it won't work.
What I can recommend is to save your patch, as follows
5 - git diff > tempchanges.patch
6 - git reset --hard # this will discard your changes, careful
7 - git checkout Y
8 - patch -p1 < tempchanges.patch
The patch may not apply cleanly :-) -- note that patch is more
tolerant of iffy merges than git's internal implementation ("git
apply") -- so it will succeed more often... but the results need
review.
There is a more git-style approach that is to use git-stash -- it uses
git-apply and may not do what you want. The steps are
5a - git stash # will save your changed files into a "stashed commit"
and clear out the changes from your working copy
6a - git checkout Y
7a - git stash apply
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] Improve --patch option documentation in git-add (updated patch)
From: Nanako Shiraishi @ 2009-09-15 10:35 UTC (permalink / raw)
To: Jari Aalto; +Cc: Sean Estabrooks, Mikael Magnusson, git
In-Reply-To: <87tyz4k4eg.fsf@jondo.cante.net>
Quoting Jari Aalto <jari.aalto@cante.net>
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Sorry, but this patch doesn't seem to apply anywhere. Have you fetched recently?
>
> Junio merged the patch at 5f2b1e6
Oh, I see.
If so, could you rebase and resend?
It would also be nicer if you followed Documentation/SubmittingPatches when composing your message, writing any additional comments after the three dashes line.
Thank you.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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