Hmmm.

This is probably unrelated but it could be a problem:
WARN  Failed to create temp dir D:\tmp\opt\gitblit\temp

Lets fix that and then how about we start with a fresh repository root folder.
Create a new repo with Gitblit.  Verify the new repo exists and then copy over one
of your existing repos into this new root folder.

Btw, I assume your git folders are ".git" and not "_git" or some other non-standard
name.

The directory exists, so that is also an incorrect message:

   dos> D:
   dos> cd \tmp\opt\gitblit\temp
   dos> dir

     Volume in drive D has no label.
     Volume Serial Number is E230-655A

     Directory of D:\tmp\opt\gitblit\temp

    2012-01-27  17:50    <DIR>          .
    2012-01-27  17:50    <DIR>          ..
    2012-01-27  17:50    <DIR>          jsp
    2012-01-27  17:50    <DIR>          webapp
    2012-01-27  18:08    <DIR>          wicketFilter-filestore
           0 File(s)              0 bytes
           5 Dir(s)  437 681 913 856 bytes free

After creating the repository using "admin" account, the console displays:

    INFO  create repository test.git
    ERROR Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener
targeted at component [MarkupContainer [Component id = editForm]] threw an exception
    org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener
targeted at component [MarkupContainer [Component id = editForm]] threw an exception
        at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:193)
        at org.apache.wicket.request.target.component.listener.ListenerInterfaceRequestTarget.processEvents(ListenerInterfaceRequestTarget.java:73)
        at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
        at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1252)
        at org.apache.wicket.RequestCycle.step(RequestCycle.java:1331)
        at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1438)
        at org.apache.wicket.RequestCycle.request(RequestCycle.java:546)
        at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486)
        at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:319)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:937)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:871)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
        at org.eclipse.jetty.server.Server.handle(Server.java:346)
        at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
        at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
        at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:535)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
        at java.lang.Thread.run(Thread.java:722)
    Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:182)
        ... 29 more
    Caused by: org.eclipse.jgit.api.errors.JGitInternalException: User config file
c:\cygwin\home\jaalto\.gitconfig invalid org.eclipse.jgit.errors.ConfigInvalidException:
Cannot read file c:\cygwin\home\jaalto\.gitconfig
        at org.eclipse.jgit.api.InitCommand.call(InitCommand.java:96)
        at com.gitblit.utils.JGitUtils.createRepository(JGitUtils.java:285)
        at com.gitblit.GitBlit.updateRepositoryModel(GitBlit.java:925)
        at com.gitblit.wicket.pages.EditRepositoryPage$1.onSubmit(EditRepositoryPage.java:230)
        at org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1595)
        at org.apache.wicket.markup.html.form.Form.process(Form.java:960)
        at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:922)
        ... 34 more
    Caused by: java.io.IOException: User config file c:\cygwin\home\jaalto\.gitconfig
invalid org.eclipse.jgit.errors.ConfigInvalidException: Cannot read file c:\cygwin\home\jaalto\.gitconfig
        at org.eclipse.jgit.storage.file.FileRepository.loadUserConfig(FileRepository.java:214)
        at org.eclipse.jgit.storage.file.FileRepository.<init>(FileRepository.java:168)
        at org.eclipse.jgit.lib.BaseRepositoryBuilder.build(BaseRepositoryBuilder.java:529)
        at org.eclipse.jgit.api.InitCommand.call(InitCommand.java:91)
        ... 40 more
    Caused by: org.eclipse.jgit.errors.ConfigInvalidException: Cannot read file c:\cygwin\home\jaalto\.gitconfig
        at org.eclipse.jgit.storage.file.FileBasedConfig.load(FileBasedConfig.java:155)
        at org.eclipse.jgit.storage.file.FileRepository.loadUserConfig(FileRepository.java:212)
        ... 43 more
    Caused by: org.eclipse.jgit.errors.ConfigInvalidException: Invalid line in config
file
        at org.eclipse.jgit.lib.Config.fromText(Config.java:1053)
        at org.eclipse.jgit.storage.file.FileBasedConfig.load(FileBasedConfig.java:143)
        ... 44 more

Result from the above:

1. The repository was not created
2. The screen displayed "internal error" message.

I'm using Windows Home Premium 64bit, Java 1.7.0_01

> Btw, I assume your git folders are ".git" and not "_git"

Yes.

The create repository screen is attached.

Hmmmm.  I develop on Win7 64-bit Pro with Java 6.  I have not tried Java 7 yet and I
don't use cygwin.  I would simplify your test setup.

I also see in the stacktrace that JGit can not load your .gitconfig.  I would peek
at that file and see if you can figure out why.  This could have everything to do with
why your repositories can't be loaded.

The HOME points to Cygwin installation /home/<logname> directory where the .gitconfig
resides. Perhaps the program could detect this case, because the file is a Cygwin symbolic
link:

  dos> type c:\cygwin\home\jaalto\.gitconfig
  !<symlink> ■vn

The few bytes from the beginning of the file are:

    dos> od -c -x 'c:\cygwin\home\jaalto\.gitconfig' | head -n 10
    0000000   #       ~   /   .   g   i   t   c   o   n   f   i   g  \n   #
           2023    2f7e    672e    7469    6f63    666e    6769    230a
    0000020  \n   #       S   e   e       h   t   t   p   :   /   /   w   w
           230a    5320    6565    6820    7474    3a70    2f2f    7777
    0000040   w   .   k   e   r   n   e   l   .   o   r   g   /   p   u   b
           2e77    656b    6e72    6c65    6f2e    6772    702f    6275
    0000060   /   s   o   f   t   w   a   r   e   /   s   c   m   /   g   i
           732f    666f    7774    7261    2f65    6373    2f6d    6967
    0000100   t   /   d   o   c   s   /   g   i   t   a   t   t   r   i   b
           2f74    6f64    7363    672f    7469    7461    7274    6269

(1) Is there a variable in gitblit.properties which could be set to point to location
of alternative HOME, that GitBlit would use, instead of system HOME variable? I could
then set up separate HOME for GitBlit's needs.

(2) After manually setting HOME to another location and copying the .gtconfig, the
backtrace no longer appears. The "test" repository gets created ok.

    dos> cd D:\tmp\tmp\gitblit
    dos> dir
    Volume in drive D has no label.
    Volume Serial Number is E230-655A

    Directory of D:\tmp\tmp\gitblit

     2012-01-28  17:32    <DIR>          .
     2012-01-28  17:32    <DIR>          ..
     2012-01-28  17:32    <DIR>          test.git
            0 File(s)              0 bytes
            3 Dir(s)  437 673 959 424 bytes free

    D:\tmp\tmp\gitblit\test.git> ls -la
    total 6
    drwx------+ 1 Administrators None   0 Jan 28 17:32 .
    drwx------+ 1 Administrators None   0 Jan 28 17:32 ..
    -rwx------+ 1 Administrators None  23 Jan 28 17:32 HEAD
    drwx------+ 1 Administrators None   0 Jan 28 17:32 branches
    -rwx------+ 1 Administrators None 392 Jan 28 17:32 config
    drwx------+ 1 Administrators None   0 Jan 28 17:32 hooks
    drwx------+ 1 Administrators None   0 Jan 28 17:32 logs
    drwx------+ 1 Administrators None   0 Jan 28 17:32 objects
    drwx------+ 1 Administrators None   0 Jan 28 17:32 refs

(3) I think where the problem is. The directories I pointed GitBlit to are Working
copies. Not "Bare Git repositories". The description in the gitblit.properties could
warn about this. Suggestion:

    # Base folder for repositories:
    # (1) Use forward slashes even on Windows!!
    #     E.g. c:/gitrepos
    # (2) Ensure that they are BARE Git repositories,
    #     not working copies (where you commit; do your work).
    # SINCE 0.5.0
    # RESTART REQUIRED
    # git.repositoriesFolder = ...

It would be nice if the error messages notified in those cases where the directories
were not detected as "BARE".

(4) After I changing git.repositoriesFolder to point to BARE repositories, all works.

1. JGit (a dependency) is looking for your .gitconfig, not Gitblit.  Perhaps there is
way to control where it looks, I'm not sure.  Symlinks, I suspect would be a big problem.
3. If Gitblit did not work with normal repositories (ones with working directories),
this would be a sensible suggestion.  But Gitblit works fine with them.  I do it all
the time.

I get the idea from your console logs that you are running Gitblit under Cygwin; don't
do that.  Cygwin is a great POSIX translation/emulation layer for GNU/Linux tools on
Windows.  Gitblit does not require POSIX emulation and is not designed for Cygwin's
symlinks and other idiosyncracies.

If you are not running Gitblit under Cygwin then I can not explain your results as
it works as expected on all platforms I have tested.

| 1. JGit (a dependency) is looking for your .gitconfig, not
| Gitblit. Perhaps there is way to control where it looks, I'm not
| sure. Symlinks, I suspect would be a big problem.

Perhaps Gitblit could make a pre-check, before letting JGit loose.

| 3. If Gitblit did not work with normal repositories (ones with
| working directories), this would be a sensible suggestion. But
| Gitblit works fine with them. I do it all the time.

In this case it don't.

| I get the idea from your console logs that you are running Gitblit
| under Cygwin; don't do that.

It's not being run under Cygwin.

The path locations point to Cygwin area, but that isn't an issue as
they are normal Windows directories and normal files to Windows to
open.

| If you are not running Gitblit under Cygwin then I can not explain
| your results as it works as expected on all platforms I have tested.

All the above was run under "dos>" (cmd.exe) as shown.

Do you have other suggestions to try, why those "Working Copy"
repositories are not recognized?

Ah.  I've never seen "dos>" prompts before, you must have set that which confused me.
 Can you zip the smallest repo and attach it to this issue?  Maybe we can determine
if its the repository or something about your setup.

So have you been successful at getting Gitblit to recognize your repositories or did
you give up?

| successful at getting Gitblit to recognize your repositories

<after starting the program and pointing git.repositoriesFolder to "Working Copies"
...>

I can't believe this. Now they are recognized. I have no explanation as I don't recall
making any significant changes anywhere.

Thought: I think you should give a warning for each repository that not "BARE". The
"Working Copies" (WCs) are *not* intended to be pushed and GitBlit server admin should
preferably use the the BARE repositories only.

Like in picture below which is a typical Git repository layout: sandboxes for each
developer + BARE for collective same project related work.

       WC   WC
         \  /
     WC - o - WC
         BARE

You don't usually "serve" your private WC, but the BARE one to other developers.

It would be nice to have also to safety belt for this:

> | 1. JGit (a dependency) is looking for your .gitconfig, not
> | Gitblit. Perhaps there is way to control where it looks, I'm not
> | sure. Symlinks, I suspect would be a big problem.

> Perhaps Gitblit could make a pre-check (at startup?), before letting JGit loose.

... i'd like to comment that GitBlit is *impressive*. Thanks for all this.

I just hope that I could have used the ISO 8601 date because that is the internationally
understood standard.

Thanks for the positive feedback.

You can use ISO8601 for display, I'm not stopping you.  Just modify your web.xml/gitblit.properties
file.

So in your setup there is 1 Gitblit server shared by multiple users and you have a
main repo (BARE) physically located alongside several WC clones of the main repo?

git.repositoriesFolder=/repos

/repos/main.git (BARE)
/repos/mainclone1 (WC)
/repos/mainclone2 (WC)
/repos/mainclone3 (WC)

That would seem like an unusual setup.  Gitblit is happy to view/serve any git repository
that is in the folder, regardless of BARE/WC status.

Ahhh... maybe you are using Gitblit in an ad-hoc setup?  i.e. there is no central Gitblit,
each developer has a Gitblit server and you push/pull from each other?  Like git instaweb?

If I think about it from that perspective I better understand the date format complaint
because I assume there are multiple Gtiblit's that would need to be configured for
ISO8601.

Perhaps you could set the access restriction to VIEW and disallow access for the other
developers.

As for issuing a warning when hosting a WC repository, I'll give that some consideration.
 There is nothing technically wrong with hosting a WC repository but I can see that
it could create confusion in an ad-hoc setup.

There is a roadmap item that I was considering for 0.9.0 to allow private repositories
(~username/repo).  Perhaps I can address your WC issue in that feature.

Let me start with Git FAQ:

    Topic: Why won't I see changes in the remote repo after "git push"?
      "A quick rule of thumb is to never push into a repository that has
      a work tree attached to it, until you know what you are doing."
      https://git.wiki.kernel.org/articles/g/i/t/GitFaq_ebc3.html

    Topic: How do I share a git public repository and use it in a CVS way?"
      "You can use git --bare init..."
      https://git.wiki.kernel.org/articles/g/i/t/GitFaq_ebc3.html

In depth explanation why non-bare is not what one wants to serve:

    "yeah yeah, but why do I need a bare repo?"
    http://sitaramc.github.com/concepts/bare.html

| So in your setup there is 1 Gitblit server shared by multiple users
| and you have a main repo (BARE) physically located alongside several
| WC clones of the main repo?
|
| git.repositoriesFolder=/repos
|
| /repos/main.git (BARE)
| /repos/mainclone1 (WC)
| /repos/mainclone2 (WC)
| /repos/mainclone3 (WC)

Not quite. The BARE repositories are used for sharing:

    git.repositoriesFolder=/repos

    /repos/project-1.git (BARE)
    /repos/project-2.git (BARE)
    /repos/project-3.git (BARE)

The GitBlit only serves the BARE repositories. Each developer clones the
bare repositoy (the clone in his WC):

     git clone <BARE address>       Developer clones project 1
     git clone <BARE address>       Developer clones project 2
     ...

Which makes the picture as described:

       WC   WC
         \  /
     WC - o - WC
         BARE

All developers can have view and commit rights.

This is the typical setup for "Git and Centalized workflow".

Similar setup is also used when a single developers interact with each
other and want to share repositories:

    Developer 1                  | Developer 2
    WC         ===>     BARE 1   | ==>> WC
    (localnet)     push   (internet) | pull/clone
                         | (no commit rights to BARE 1)
                         |
    pull/clone     <==   |  BARE 2   <== push
             | (internet)

In this picture each developer has their own GitBlit (at point "|");
view only, no commit rights. That is the typical Git workflow:

   [developer 1 / at hostA]
   cd <BARE 1>
   git --bare init
   cd <WC>
   git remote add origin <location of BARE 1>
   git push origin master
   ...

   [developer 2 / at hostB]
   git clone <BARE 1>
   ... hack ...
   cd <BARE 2>
   git --bare init
   cd <WC>
   git push <BARE 2>
   ...notify developer 1 that chnages can be pulled
   ...or developer 1 can check developer's 2 GitBlit.

| I assume there are multiple Gtiblit's that would need to be configured for ISO8601.

YEs, especially when people interact each other I don't the other end would appreciate
reading Finnish locale months. The problem with English month names is the same. I
can never remember in which order to spell then, nor to map the month in numbers (did
September go before or after October; what numeric month was it?

If the default setup would be ISO 8601, GitBlit would be internationally ready instantly
without extra setup or coordination with others. Besides, ISO 8601 is perfect in computer
related software (compare to "git log --date=short" which uses ISO date representation).
The other benefits are that numeric representation is clear, compact, an unambiguous
and easily formatted in confined space (the char count is also always predictable):

   2010-12-01
   2011-03-25
   2012-07-30
   ...

Also found this:

   "In Git (from version 1.7.0 and above) the repository has to be "bare" 
   (no working files) in order to accept a push."
   http://www.bitflop.com/document/111

... at in git-config(1) manual page:

receive.denyCurrentBranch::
        If set to true or "refuse", git-receive-pack will deny a ref update
        to the currently checked out branch of a non-bare repository.
        Such a push is potentially dangerous because it brings the HEAD
        out of sync with the index and working tree. If set to "warn",
        print a warning of such a push to stderr, but allow the push to
        proceed. If set to false or "ignore", allow such pushes with no
        message. Defaults to "refuse".

Gitblit was designed for centralized workflow (think Github), not distributed peer-peer
push/pull workflow which is what you are describing.  1st image here http://progit.org/book/ch5-1.html

I think what I will do is have a setting to hide repositories with working copies from
Gitblit for scenarios like yours: distributed push/pull where you are mixing your personal
repositories and your public repositories in the same folder.

Alternatively, if git.repositoriesFolder only had your public repos and you put your
WC clones in another folder you would not need this change.

Dates.
Here are the current defaults.
web.timeFormat = HH:mm
web.datestampShortFormat = yyyy-MM-dd
web.datestampLongFormat = EEEE, MMMM d, yyyy
web.datetimestampLongFormat = EEEE, MMMM d, yyyy h:mm a z

The first two are already 8601.  The next two are more descriptive and I don't want
them to be 8601.  The first two are used in places like the log page which is the analog
of "git log --date=short".  The second two are used on the commit pages, tag pages,
etc and they are just about the same (but not identical) to the output of "git log".
 I will change the default of the last one to be EEEE, MMMM d, yyyy HH:mm Z to almost
match Git.

Have you tried setting web.useClientTimezone?

That will use the above patterns combined with YOUR browser-reported timezone and should
display month and day of week in your native tongue thus solving your main complaint.

Wow, this is becoming an lengthy issue.  :)

Ok, you have convinced me that pushing to a non-bare repository can do Bad Things (tm).

This is what I propose:

1. I will block pushes to a repository with a working copy.
2. I will indicate (somehow) on the summary page that the repository has a working
copy.
3. I will try to find room to indicate on the repositories list that the repository
has a working copy.  Perhaps with an asterisk next to the name or something like that.
4. I will implement a setting to hide all repositories with working copies.

Does that sound agreeable to you?

| Gitblit was designed for centralized workflow (think Github), not
| distributed peer-peer push/pull workflow which is what you are
| describing.  1st image here http://progit.org/book/ch5-1.html
|
| I think what I will do is have a setting to hide repositories with

Please don't :-) I might want to browse WCs.

| working copies from Gitblit for scenarios like yours: distributed
| push/pull where you are 
|
| mixing your personal repositories and your public repositories in
| the same folder.

Oh, that was not the case. They were both in separate directories all
the time.

What I ment, that if the git.repositoriesFolder was set to directory
or WC repositories, it would display warning to the command line (I
use the *.bat starter command) for those:

   (WARN: Not a bare repository).

From the UI side an icon like "exclamation mark inside blue ball" or
similar could mark repositories in view which are WCs and would be
beter off not to enable any push actions.

     (!)

That was what I had in mind.


| 1. I will block pushes to a repository with a working copy.

Yes. I don't think push should be made possible form GitBlit to WCs.
Experienced users can do these kind of things; from command line.

| 2. I will indicate (somehow) on the summary page that the repository has a working
copy.

Put also comment next to  git.repositoriesFolder

| 3. I will try to find room to indicate on the repositories list that the repository
has a working copy.  Perhaps with an asterisk next to the name or something like that.

Excellent.

| 4. I will implement a setting to hide all repositories with working copies.

Excellent.

One again,
Thanks.

Fixed in v0.9.1

Fixed in v0.9.1. Closing.