[MonoDevelop] Patch - Support for Git Initial Commit

[Dale Ragan]

My thoughts,

>> Depends. For some libraries we ship copies from source in contrib
>> (e.g. NRefactory, Cecil), but for others we ship binaries in the
>> addins (e.g. NUnit, Mono.Debugger.Soft). Debian/Ubuntu packagers hate
>> binaries, but they're a lot simpler for us to deal with, so I'd
>> suggest going that route initially.
>>
>
> I also hate this.
>
> I hate it for many reasons:
> * Not easy to upgrade the code
> * Not easy to figure out which branch the code came from
> * Not possible to track any changes that were made
> * We end up with binaries on the tree, and I detest binaries
> * We cant fix the code trivially if we wanted to
> * It annoys every packager in the world
> * No transparency as to what is behind the binaries
>
> The better option is to either make it a build-time requirement to have
> the
> package properly installed and available, or alternatively put the source
> code side-by-side in the tree if we really need to keep all the source
> code
> in place.
>
> With GitSharp in particular, we will run into the issue that the library
> will likely require Linux-specific and Mac-specific changes as the
> GitSharp
> hackers seem to be mostly Windows hackers.   A binary is the worst
> possible
> thing we can do.

Well, I assume the Mono and MonoDevelop projects will be moved to Git
before MonoDevelop 2.6 is released?  If that's the case, I would like to
present two options for a temporary basis.  Once we move to Git, we can
use one of Git's many ways to combine the projects from a fork of GitSharp
controlled by the MonoDevelop team.

  1. Put the binary in with MonoDevelop until the move.  As I update
     the binary during development of the add-in, I will include the
     hash of the commit from my fork for reference.

  2. Modify the build to grab the source from my fork based on a tag or
     branch name and put the clone in a directory we decide for the build.

On another note, they are definitely Windows hackers.  They use CRLF for
the line endings in the repository.  I cloned my repository last night on
my Linux box and I was greeted with a slew of changes when checking status
right after the clone.  I had to set autocrlf to false for the repository,
due to my global setting being set to input.  Since Git can be told to
convert the newlines to the system’s standard when checking out files, and
to LF newlines when committing in by making Windows developer's set
autocrlf to true.  I decided to submit a message to Henon about a change
to make cross platform development more smoother by keeping the line
endings in the repo to LF.  He posted a message to the mailing list to
discuss the change to LF.

Later,

Dale