fast-import working?
Ted Dennison
trouble. I'm wondering if its working, or if I'm hitting known issues.
For one thing, it has trouble with my commit line. Here's what I'm
getting (starting with a cmd.exe window in XP or Vista):
C:\> c:\msysgit\bin\sh -login -i
Welcome to msysGit
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
Ted@ATLANTIS /c
$ mkdir Gittest
Ted@ATLANTIS /c
$ cd Gittest
Ted@ATLANTIS /c/Gittest
$ git init
Initialized empty Git repository in .git/
Ted@ATLANTIS /c/Gittest
$ git fast-import
commit refs/heads/master
fatal: Branch name doesn't conform to GIT standards: refs/heads/master
fast-import: dumping crash report to .git/fast_import_crash_2352
The same sequence of commands seems to work fine with the Cygwin
version. Is this perhaps a line ending issue?
Also, how the heck do I send an EOF to this to get it to shut down
nicely? Hitting CTRL-D works with Cywgin, but doesn't seem to do
anything with the msys version.
--
T.E.D.
--
Why, I'd horse-whip you if I had a horse. -- Groucho Marx
mobiled...@gmail.com
Johannes Schindelin
On Wed, 9 Apr 2008, Ted Dennison wrote:
> Ted@ATLANTIS /c/Gittest
> $ git fast-import
> commit refs/heads/master
> fatal: Branch name doesn't conform to GIT standards: refs/heads/master
> fast-import: dumping crash report to .git/fast_import_crash_2352
>
> The same sequence of commands seems to work fine with the Cygwin
> version. Is this perhaps a line ending issue?
Most probable. Could you patch fast-import.c to strip the carriage
return? Most likely the proper place would be read_next_command(), maybe
these two lines at the end:
if (command_buf.len && command_buf.buf[command_buf.len - 1] == '\r')
strbuf_setlen(&command_buf, command_buf.len - 1);
> Also, how the heck do I send an EOF to this to get it to shut down
> nicely? Hitting CTRL-D works with Cywgin, but doesn't seem to do
> anything with the msys version.
Funny. I always thought that fast-import.c was not for interactive use
:-) Frankly, I have no idea what to do if Ctrl+D does not work.
Ciao,
Dscho
Ted Dennison
> Most probable. Could you patch fast-import.c to strip the carriage
> return? Most likely the proper place would be read_next_command(), maybe
>
>
> Funny. I always thought that fast-import.c was not for interactive use
> :-) Frankly, I have no idea what to do if Ctrl+D does not work.
>
T.E.D.
--
It's extremely hard to fold a Buffalo.
Peter Harris
>
> Also, how the heck do I send an EOF to this to get it to shut down nicely?
> Hitting CTRL-D works with Cywgin, but doesn't seem to do anything with the
> msys version.
WinDOS EOF is CTRL-Z. (WinDOS doesn't have a "suspend". DOS doesn't
multitask, and Windows "suspend" is "minimize the window, open a new
one")
Peter Harris
Steffen Prohaska
On Apr 10, 2008, at 5:58 AM, mobiled...@gmail.com wrote:
> Is there a new git release around the last release was about 2
> months ago?
No. Before I'll create a new installer, some work is needed to make
all tests pass. Unfortunately, I am currently lacking time to work on
this.
Steffen
mobiled...@gmail.com
i m waiting for an amazing explosive release from you guys including cheetah that ll blow our minds away :)
This is one of the best products after tortoisesvn to hit the market that changes the way a developer works in windows
Johannes Schindelin
[please do not top-post!]
On Thu, 10 Apr 2008, mobiled...@gmail.com wrote:
> ok cool
> i m waiting for an amazing explosive release from you guys including cheetah
> that ll blow our minds away :)
Unfortunately, it seems that more and more people just wait for a new
release. I, for one, decided not to do anything, waiting in the shadows
just like everybody else, too.
Ciao,
Dscho
Ted Dennison
> Most probable. Could you patch fast-import.c to strip the carriage
> return? Most likely the proper place would be read_next_command(), maybe
> these two lines at the end:
>
> if (command_buf.len && command_buf.buf[command_buf.len - 1] == '\r')
> strbuf_setlen(&command_buf, command_buf.len - 1);
>
I can check that in if you want. However, I'd think for ease of future
reintegration you might prefer to bracket it in an "ifdef __MINGW32__"
like I've seen in some other sources. For instance, buildtin-tag.c has
an ifdef for roughly the same line-ending issue.
Hopefully tomorrow I'll get a chance to see if that fixes my problems
with the non-interactive use of fast-import.
--
T.E.D.
--
Diplomacy is the art of saying 'Nice doggie' until you can find a rock.
-- Will Rogers
Ted Dennison
> WinDOS EOF is CTRL-Z. (WinDOS doesn't have a "suspend". DOS doesn't
>
"return". That seems to work. Thanks.
I know this isn't the proper list for design issues, but fast-import
probably should have some kind of "quit" command. The EOF thing really
feels like a hack.
--
T.E.D.
--
I used to be Snow White but I drifted. -- Mae West
Ted Dennison
>
> Peter Harris wrote:
>> WinDOS EOF is CTRL-Z. (WinDOS doesn't have a "suspend". DOS doesn't
>>
> I had tried that. However, I didn't think to hit that and then hit
> "return". That seems to work. Thanks.
>
> I know this isn't the proper list for design issues, but fast-import
> probably should have some kind of "quit" command. The EOF thing really
> feels like a hack.
sends an EOF from a Windows console *only* if it is the first character
on the line, and only after the line is fed to the console.
But wait! There's more! If you instead create a console process and feed
its input through a pipe (what I happened to be attempting to do), there
is *no* way to send EOF. ctrl-z and ctrl-d are passed straight through
as-is. Closing the pipe won't do it either. It sends an entirely
different error code than EOF, which most programs (including
fast-import) interpret as an error. For a more detailed discussion of
this, see http://discuss.techinterview.org/default.asp?joel.3.218214.22
This essentially means fast-import, as currently designed, cannot work
in a detached NT process. Thus the "quit" command I talked about above
is no longer a "nice to have", its a necessity.
I tried it out, and it works great. (I called the command "done",
actually). Its only 2 lines of code in the command-handling if check. It
should be totally backward-compatable too. So what I'm wondering now who
I should talk to about possibly getting this change merged into the Git
baseline. Would the proper place be msysgit, or somewhere upstream?
--
T.E.D.
--
Jesus saves. Moses invests. Cthulhu repossesses
Ted Dennison
>
> Johannes Schindelin wrote:
>> Most probable. Could you patch fast-import.c to strip the carriage
>> return? Most likely the proper place would be
> with the non-interactive use of fast-import.
working now.
In fact, I think it was entirely the EOF issue that was hosing me. When
run non-interactively, I can avoid the line-ending issue by just sending
the line-ending that fast-import is looking for.
--
T.E.D.
--
Um, l...Look, if we build this large wooden badger...
Johannes Schindelin
On Thu, 10 Apr 2008, Ted Dennison wrote:
> Johannes Schindelin wrote:
> > Most probable. Could you patch fast-import.c to strip the carriage return?
> > Most likely the proper place would be read_next_command(), maybe these two
> > lines at the end:
> >
> > if (command_buf.len && command_buf.buf[command_buf.len - 1] == '\r')
> > strbuf_setlen(&command_buf, command_buf.len - 1);
> >
> That did the trick.
>
> I can check that in if you want. However, I'd think for ease of future
> reintegration you might prefer to bracket it in an "ifdef __MINGW32__"
> like I've seen in some other sources.
I do not like that ifdef... Rather have something like
HAS_DOS_LINE_ENDINGS. IIRC Hannes did something like that in recent
versions of his big mingw2upstream patch.
Ciao,
Dscho