Чел съм достатъчно, за да знам че гит не е подходящ за нашата работа. Трябва си ни централизирано хранилище, при това ударението е в централизирано.
Не очаквах, обаче, че имплементацията на гит-а ще е толкова ограничена. В смисъл няма теоретична причина гит да не може се ползва за централно хранилище. То на практика го подкарах и става, ама е адски неудобно. Не мога да преценя каква част от ограниченията идват от самия гит и каква от калпавите плъгини на еклипс... може би в бъдещи версии софтуерите им ще се оправят, но за съжаление в момента има мноооого какво да се желае.
Това да трябва да сваляш хранилище, само за да го разгледаш е тъпо. Да трябва да сваляш цялото е още по-тъпо. А като добавим и как гитхъба подтиква да се клонират хранилища от всеки се получава супер тъпа каша от чукурнайсет отдалечени хранилища, локални хранилища... и последния да затвори вратата...
Да имаш възможност да работиш с много хранилища би било предимство, но като те принуждават да работиш с много си е недостатък.

Както и да е.... не ми се занимава повече. За щастие гитхъба бачка и с SVN интерфейс и така ще го ползвам засега.

току-що след "share project" даде грешка и междувременно ми забърса целия локален проект.

Бахти, ами ако нямах копие?!
Не знам колко голям малоумник трябва да си, че да напишеш софтуер който при опит за експорт на проект да ти го изтрива... Всъщност може би трябва да се радвам, че поне не ми форматира дисковете... Аз бях дотук с git-a.

Наскоро ми попадна един интересен проект- Fossil (http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki). Писан е от създателя на SQLite. За сега web базирани хостинги има само два (или аз поне не съм открил повече)-SourceForge и Chisel (http://chiselapp.com/) като в Chisel мисля, че може да си заключваш репозиториите кой да има достъп до тях. Давам го просто идейно.

Това може да помогне - обясняват GIT като за SVN юзери
https://www.atlassian.com/git/tutorials ... d-workflow

Няма какво да ми се обяснява, то ми изтри данните без да ме пита и без да ги качи някъде. И аз правя грешки, ама тва си е ебахти бъгливата история...

Не бъди злопаметен де
То и "rm -rf" трие без да пита ...

Като съвестен радетел на open source-а е редно да вземеш мерки. Първо репродуцираш и анализираш проблема за да знаеш дали на eGit тийма или на Линус директно да репортваш
После или пишеш репорта, или намираш бъга и пращаш пач.
Git-а е GPLv2, eGit-а е сигурно EPL. Т.е. съдържат "no warranty" нейде из дълбините си.
Това е бъгзилата на eGit:
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=EGit&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=exact&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
Както виждаш проблеми си има и то не малко. Не съм търсил дали има нещо подобно на твоето.
Така е с повечето неща из Еклипса. Проблеми има но ако си ентусиаст го ползваш, ако не плащаш за нещо с професионален support, за да не ти се налага да псуваш по затънтени форуми (т.е. дават ти се право официално да псуваш по телефон/email).

Да не остана неразбран, аз си го ползвам и му се радвам на Еклипса. Но винаги трябва да имаш едно наум. Положението със SVN team provider-а не е по-розово:
https://bugs.eclipse.org/bugs/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Technology&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=Subversive&query_format=advanced&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr

gicho,
Open source за мен е вид бизнес практика. Естествено я предпочитам и ползвам, когато е възможно. Но в случая, твърдо нямам намерение да ползвам гит и няма да седна пак да се мъча да пробвам да пресъздавам бъговете, да ги документирам и/или оправям. Не виждам причина, пак ще повторя че за мен опън сорса е бизнес модел, а не самарянство или благотворителност и т.н.

По всяка вероятност проблема е някъде из eGit-а. Досега не съм правиш първоначално "share"-ване на проект от там, ако остане време ще пробвам дали ще имам същия проблем.
Но това не бива да води до грешни изводи за git-а като цяло.

Гафът вероятно стана заради проблем с пътищата...
В google.code акаунта ми беше един и съответно хранилището е едно, но аз си качвах различни проекчета като поддиректории. Самият SVN не се интересува каква ти е организацията, проекти и т.н. Просто имаш едно хранилище на сървъра, а локално може да го свалиш цялото или част или много и независими части.
При гит-а, обаче явно не е съвсем така. Аз си свалих първо основния проект и то ми създаде локално гит хранилище. После като опитах да свалям друго проектче не стана, все нещо не му харесваше. Тогава почнах да си играя с пътищата, щото то нали отделно се въвежда URL на сървъра, отделно път в сървъра, отделно локални пътища.
Предполагам, проблема се получи щото като свалях основния проект в локалното хранилище ми свали само неговата директория. Докато на съвръра има и други директории. И после явно говедото е решило, че след като му давам един и същ главен пък към отдалеченото хранилище, трябва и локалното хранилище да е същото и тръгна да синхронизира с локалното. И без да ме пита, нито предупреждава реши че трябва да изтрие файловете дето му давам.

Много ме съмнява точно git да е виновен.
Никога, ама никога не изтрива файлове без предупреждение особенно пък безвъзвратно.
Все пак идеята му е да пази история на промените и да можеш винаги да се върнеш назад във времето.
Проблема ти е, че си си решил, че не е читав и не искаш повече да се занимаваш ... ти си знаеш.