www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - BitBucket Offers Git Support

reply Caligo <iteronvexor gmail.com> writes:
I just found out that Bitbucket finally offers Git support.  I wonder,
would anyone else like to see GDC switch to Git?  I would like to kindly
make a request because it would make things little easier.
Nov 01 2011
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 02-11-2011 06:23, Caligo wrote:

 I just found out that Bitbucket finally offers Git support.  I wonder,
 would anyone else like to see GDC switch to Git?  I would like to kindly
 make a request because it would make things little easier.


GDC in Git would definitely be great. Personally I think it would be 
awesome if it was part of the GitHub organization though. :)

- Alex
Nov 02 2011
prev sibling next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
02.11.2011 8:23, Caligo пишет:

 I just found out that Bitbucket finally offers Git support.  I wonder,
 would anyone else like to see GDC switch to Git?  I would like to kindly
 make a request because it would make things little easier.


What things? I see, that every one switches to Git, but what the 
purpose? I don't have a deep knowledge about DVCS-s, but I'm really 
interested in what Git functionality is missing in Hg for you?

Is it:
* discarding previously pulled branches;
* pruning old revision data from the local repository;
* unlimited number of parent revisions during a merge;
* rebasing;
* infinite power of `git-push --force`?

Only the first one looks good for me, but the last one scares me because 
you can loose the remote repository (and I really sow it frightens 
people). Others are looking seldom applicable.

So why does Git advantages worth:
* Git complexity (in comparison with Hg);
* ability to loose the remote repository;
* lack of file rename/copy support;
* periodic maintenance with git-gc?


I don't hate Git. I just don't understand the current opinion and would 
be glad if someone will base is for me, TIA.
Nov 02 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 02-11-2011 11:07, Denis Shelomovskij wrote:

 02.11.2011 8:23, Caligo пишет:

 I just found out that Bitbucket finally offers Git support. I wonder,
 would anyone else like to see GDC switch to Git? I would like to kindly
 make a request because it would make things little easier.


 What things? I see, that every one switches to Git, but what the
 purpose? I don't have a deep knowledge about DVCS-s, but I'm really
 interested in what Git functionality is missing in Hg for you?

 Is it:
 * discarding previously pulled branches;
 * pruning old revision data from the local repository;
 * unlimited number of parent revisions during a merge;
 * rebasing;
 * infinite power of `git-push --force`?

 Only the first one looks good for me, but the last one scares me because
 you can loose the remote repository (and I really sow it frightens
 people). Others are looking seldom applicable.

 So why does Git advantages worth:
 * Git complexity (in comparison with Hg);
 * ability to loose the remote repository;
 * lack of file rename/copy support;
 * periodic maintenance with git-gc?


 I don't hate Git. I just don't understand the current opinion and would
 be glad if someone will base is for me, TIA.


Minor correction: Git does have rename/move support; see git mv. I do 
not see why a VCS needs to be copy-aware.

I generally point people to http://whygitisbetterthanx.com/ when they 
ask why Git is great, though personally these are the features I like:

1) Sane branching/tagging.
2) Better EOL handling (see core.autocrlf).
3) Rebasing.
4) Stashing.
5) Non-sacred history.

I'll elaborate:

1) Branching is pretty much the only way you can really screw up in Hg. 
AFAIK, there still is no good way to revert an erroneous branch merge.
2) Hg requires setting up the win32text extension for this, while Git 
simply asks that you set a configuration option.
3) This is absolutely essential in distributed development. When you 
work on a large feature in a fork, you typically end up with lots of 
commits. When you send this work upstream, you don't want to cause noise 
in the history. Rebasing helps in avoiding this by squashing commits 
together to get a nice, clean history.
4) I'm sure Hg has some similar command, but I really like Git's way of 
using a stack for stashing.
5) Again, this is useful when doing distributed development mostly. As 
you point out, rewriting history in the upstream repository _is_ a 
really bad idea.

- Alex
Nov 02 2011
next sibling parent reply Kagamin <spam here.lot> writes:
Alex Rønne Petersen Wrote:


 3) This is absolutely essential in distributed development. When you 
 work on a large feature in a fork, you typically end up with lots of 
 commits. When you send this work upstream, you don't want to cause noise 
 in the history. Rebasing helps in avoiding this by squashing commits 
 together to get a nice, clean history.


I thought, a developer pushes his changes as a branch, which is later merged to
main. Merge is done as one big commit, so the main branch looks like 1. merge
database, 2. merge collections, 3. merge gui - isn't this your clean history?
Nov 02 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 02-11-2011 16:33, Kagamin wrote:

 Alex Rønne Petersen Wrote:


 3) This is absolutely essential in distributed development. When you
 work on a large feature in a fork, you typically end up with lots of
 commits. When you send this work upstream, you don't want to cause noise
 in the history. Rebasing helps in avoiding this by squashing commits
 together to get a nice, clean history.


 I thought, a developer pushes his changes as a branch, which is later merged
to main. Merge is done as one big commit, so the main branch looks like 1.
merge database, 2. merge collections, 3. merge gui - isn't this your clean
history?


The merge itself can be a commit (if you use git merge instead of git 
pull), but there is no reason to eliminate the *entire* history when 
pulling in a branch. That's just the SVN way of doing things, which is 
just silly.

Folding commits together makes sense if you have, say, one commit 
implementing some feature and two subsequent commits adding minor fixes 
to it.

- Alex
Nov 02 2011
parent reply Kagamin <spam here.lot> writes:
Alex R�nne Petersen Wrote:


 On 02-11-2011 16:33, Kagamin wrote:

 Alex Rønne Petersen Wrote:


 3) This is absolutely essential in distributed development. When you
 work on a large feature in a fork, you typically end up with lots of
 commits. When you send this work upstream, you don't want to cause noise
 in the history. Rebasing helps in avoiding this by squashing commits
 together to get a nice, clean history.


 I thought, a developer pushes his changes as a branch, which is later merged
to main. Merge is done as one big commit, so the main branch looks like 1.
merge database, 2. merge collections, 3. merge gui - isn't this your clean
history?


 
 The merge itself can be a commit (if you use git merge instead of git 
 pull), but there is no reason to eliminate the *entire* history when 
 pulling in a branch.


Isn't the merge commit connected with the branch it was merged from? So if you
want history of the branch, it's still there, it's just not main's history.
Nov 02 2011
parent reply Kagamin <spam here.lot> writes:
 The merge itself can be a commit (if you use git merge instead of git 
 pull), but there is no reason to eliminate the *entire* history when 
 pulling in a branch.


 
 Isn't the merge commit connected with the branch it was merged from? So if you
want history of the branch, it's still there, it's just not main's history.


An example from Fossil:
20 recent commits: http://www.fossil-scm.org/index.html/timeline
20 recent commits in trunk:
http://www.fossil-scm.org/index.html/timeline?r=trunk
Nov 02 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 02-11-2011 17:03, Kagamin wrote:

 The merge itself can be a commit (if you use git merge instead of git
 pull), but there is no reason to eliminate the *entire* history when
 pulling in a branch.


 Isn't the merge commit connected with the branch it was merged from? So if you
want history of the branch, it's still there, it's just not main's history.


 An example from Fossil:
 20 recent commits: http://www.fossil-scm.org/index.html/timeline
 20 recent commits in trunk:
http://www.fossil-scm.org/index.html/timeline?r=trunk


That only makes sense if you keep the branches around after they're 
'dead', which is considered a bad practice, as it will eventually grow 
confusing.

- Alex
Nov 02 2011
parent reply Kagamin <spam here.lot> writes:
Alex R�nne Petersen Wrote:


 On 02-11-2011 17:03, Kagamin wrote:

 The merge itself can be a commit (if you use git merge instead of git
 pull), but there is no reason to eliminate the *entire* history when
 pulling in a branch.


 Isn't the merge commit connected with the branch it was merged from? So if you
want history of the branch, it's still there, it's just not main's history.


 An example from Fossil:
 20 recent commits: http://www.fossil-scm.org/index.html/timeline
 20 recent commits in trunk:
http://www.fossil-scm.org/index.html/timeline?r=trunk


 
 That only makes sense if you keep the branches around after they're 
 'dead', which is considered a bad practice, as it will eventually grow 
 confusing.


They're not dead. They're history.
Nov 02 2011
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 02-11-2011 18:59, Kagamin wrote:

 Alex R�nne Petersen Wrote:


 On 02-11-2011 17:03, Kagamin wrote:

 The merge itself can be a commit (if you use git merge instead of git
 pull), but there is no reason to eliminate the *entire* history when
 pulling in a branch.


 Isn't the merge commit connected with the branch it was merged from? So if you
want history of the branch, it's still there, it's just not main's history.


 An example from Fossil:
 20 recent commits: http://www.fossil-scm.org/index.html/timeline
 20 recent commits in trunk:
http://www.fossil-scm.org/index.html/timeline?r=trunk


 That only makes sense if you keep the branches around after they're
 'dead', which is considered a bad practice, as it will eventually grow
 confusing.


 They're not dead. They're history.


I don't understand what point you're trying to argue. :)

- Alex
Nov 02 2011
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Alex Rønne Petersen Wrote:


 Isn't the merge commit connected with the branch it was merged from? So if you
want history of the branch, it's still there, it's just not main's history.


 An example from Fossil:
 20 recent commits: http://www.fossil-scm.org/index.html/timeline
 20 recent commits in trunk:
http://www.fossil-scm.org/index.html/timeline?r=trunk


 That only makes sense if you keep the branches around after they're
 'dead', which is considered a bad practice, as it will eventually grow
 confusing.


 They're not dead. They're history.


 
 I don't understand what point you're trying to argue. :)
 
 - Alex


You are both correct, but due to git's high level once you do a merge you don't
see the history as multiple branches. A merge commit will reference both branch
data as its parent. The branch name can then be removed and its history remain
part of the master branch.

Also if you merge in a branch that is a direct descendant the merge is a
"Fast-Forward" which just means make master point to ____ commit. This makes it
common to always commit non-master branch, and still a merge commit isn't
required.
Nov 02 2011
parent reply Kagamin <spam here.lot> writes:
Jesse Phillips Wrote:


 You are both correct, but due to git's high level once you do a merge you
don't see the history as multiple branches. A merge commit will reference both
branch data as its parent. The branch name can then be removed and its history
remain part of the master branch.
 
 Also if you merge in a branch that is a direct descendant the merge is a
"Fast-Forward" which just means make master point to ____ commit. This makes it
common to always commit non-master branch, and still a merge commit isn't
required.


Do I understand it right, that "sacred history problem" is a problem only for
git due to how it implements merges?

Also if you can always fast forward the main branch, does it mean the project
is small, i.e. ~1 man is working on it?
Nov 03 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 03-11-2011 11:33, Kagamin wrote:

 Jesse Phillips Wrote:


 You are both correct, but due to git's high level once you do a merge you
don't see the history as multiple branches. A merge commit will reference both
branch data as its parent. The branch name can then be removed and its history
remain part of the master branch.

 Also if you merge in a branch that is a direct descendant the merge is a
"Fast-Forward" which just means make master point to ____ commit. This makes it
common to always commit non-master branch, and still a merge commit isn't
required.


 Do I understand it right, that "sacred history problem" is a problem only for
git due to how it implements merges?

 Also if you can always fast forward the main branch, does it mean the project
is small, i.e. ~1 man is working on it?


No, Git is probably the DVCS with *least* sacred history (read: nothing 
is sacred).

- Alex
Nov 03 2011
parent reply Kagamin <spam here.lot> writes:
 Do I understand it right, that "sacred history problem" is a problem only for
git due to how it implements merges?

 Also if you can always fast forward the main branch, does it mean the project
is small, i.e. ~1 man is working on it?


 
 No, Git is probably the DVCS with *least* sacred history (read: nothing 
 is sacred).


I meant, sacred history would be a problem only in git and is not a problem for
other DVCSes where merges are done properly.
Nov 03 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 03-11-2011 15:06, Kagamin wrote:

 Do I understand it right, that "sacred history problem" is a problem only for
git due to how it implements merges?

 Also if you can always fast forward the main branch, does it mean the project
is small, i.e. ~1 man is working on it?


 No, Git is probably the DVCS with *least* sacred history (read: nothing
 is sacred).


 I meant, sacred history would be a problem only in git and is not a problem
for other DVCSes where merges are done properly.


It's not just related to merges. With sacred history, you lose the 
ability to rebase, too.

- Alex
Nov 03 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Alex R�nne Petersen Wrote:


 That only makes sense if you keep the branches around after they're
 'dead', which is considered a bad practice, as it will eventually grow
 confusing.


 They're not dead. They're history.


 
 I don't understand what point you're trying to argue. :)


You sound as if keeping the history is a bad practice.
Nov 03 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 03-11-2011 11:35, Kagamin wrote:

 Alex R�nne Petersen Wrote:


 That only makes sense if you keep the branches around after they're
 'dead', which is considered a bad practice, as it will eventually grow
 confusing.


 They're not dead. They're history.


 I don't understand what point you're trying to argue. :)


 You sound as if keeping the history is a bad practice.


No no, keeping the history by pulling it into mainline and *then* 
deleting the branch is what I suggest doing.

- Alex
Nov 03 2011
prev sibling parent reply Caligo <iteronvexor gmail.com> writes:
This wasn't supposed to be about Git vs Mercurial.  I should have been more
clear in my post!

The reason it would make things easier if we switched to using Git on
Bitbucket is because it would make things more streamlined.  I don't like
how I need to use Mercurial when I want to work on GDC, then switch back to
Git when working on DMD.  It would even be better if both projects were
using the same hosting site.
Nov 02 2011
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Caligo wrote:

 This wasn't supposed to be about Git vs Mercurial.  I should have been
 more clear in my post!
=20
 The reason it would make things easier if we switched to using Git on
 Bitbucket is because it would make things more streamlined.  I don't
 like how I need to use Mercurial when I want to work on GDC, then switc=


h

 back to Git when working on DMD.  It would even be better if both
 projects were using the same hosting site.


	You can always use hg-git [1] to do everything with Mercurial
whether you're working on GDC or DMD...

		Jerome

[1] http://mercurial.selenic.com/wiki/HgGit
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Nov 02 2011
parent "Nick Sabalausky" <a a.a> writes:
""Jérôme M. Berger"" <jeberger free.fr> wrote in message 
news:j8sf42$d3$1 digitalmars.com...

 You can always use hg-git [1] to do everything with Mercurial
whether you're working on GDC or DMD...


hg-git only barely works. I've completely given up on it after wasting too 
much time and effort on showstopper problems.
Nov 03 2011
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Caligo (iteronvexor gmail.com)'s article

 --bcaec5196a6589aea504b0c47177
 Content-Type: text/plain; charset=ISO-8859-1
 This wasn't supposed to be about Git vs Mercurial.  I should have been more
 clear in my post!
 The reason it would make things easier if we switched to using Git on
 Bitbucket is because it would make things more streamlined.  I don't like
 how I need to use Mercurial when I want to work on GDC, then switch back to
 Git when working on DMD.  It would even be better if both projects were
 using the same hosting site.


Could probably sort something out. :)
Nov 02 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 02.11.2011 11:00, Alex Rønne Petersen wrote:

 On 02-11-2011 11:07, Denis Shelomovskij wrote:

 02.11.2011 8:23, Caligo пишет:

 I just found out that Bitbucket finally offers Git support. I wonder,
 would anyone else like to see GDC switch to Git? I would like to kindly
 make a request because it would make things little easier.


 What things? I see, that every one switches to Git, but what the
 purpose? I don't have a deep knowledge about DVCS-s, but I'm really
 interested in what Git functionality is missing in Hg for you?

 Is it:
 * discarding previously pulled branches;
 * pruning old revision data from the local repository;
 * unlimited number of parent revisions during a merge;
 * rebasing;
 * infinite power of `git-push --force`?

 Only the first one looks good for me, but the last one scares me because
 you can loose the remote repository (and I really sow it frightens
 people). Others are looking seldom applicable.

 So why does Git advantages worth:
 * Git complexity (in comparison with Hg);
 * ability to loose the remote repository;
 * lack of file rename/copy support;
 * periodic maintenance with git-gc?


 I don't hate Git. I just don't understand the current opinion and would
 be glad if someone will base is for me, TIA.


 Minor correction: Git does have rename/move support; see git mv. I do
 not see why a VCS needs to be copy-aware.

 I generally point people to http://whygitisbetterthanx.com/ when they
 ask why Git is great, though personally these are the features I like:


Why point people there? That's a dreadful page! Here are his arguments:
*cheap local branching. OK.
*everything is local. INVALID. This applies to any DVCS.
*git is fast. INVALID. Not true on Windows, and the timing data is 
obsolete (the other systems have caught up).
*git is small. INVALID. This is obsolete data (the other systems have 
caught up).
*the staging area. OK.
*distributed. INVALID. This applies to any DVCS.
*any workflow. Maybe. Though other DVCS's are pretty flexible.
*github. OK.

and then he finishes with:
*easy to learn
What is that guy smoking?????

That page is really, really bad publicity for git. They should update 
it, or take it down.
Nov 02 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 03 Nov 2011 03:24:51 +0200, Don <nospam nospam.com> wrote:


 Why point people there? That's a dreadful page! Here are his arguments:


Note that each item is addressed with regards to specific alternatives.  
For example, the page only implies that Git is easy to learn in comparison  
with Perforce.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Nov 02 2011
parent "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.v4ckapeytuzx1w cybershadow.mshome.net...

 On Thu, 03 Nov 2011 03:24:51 +0200, Don <nospam nospam.com> wrote:


 Why point people there? That's a dreadful page! Here are his arguments:


 Note that each item is addressed with regards to specific alternatives. 
 For example, the page only implies that Git is easy to learn in comparison 
 with Perforce.


Yea, but the end result is that if you use that page to compare Git to any 
one of the other VCSes, he only lists a small amount of Git advantages, and 
ignores the fact that the other one has advantages, too. And despite that, 
he's concluding that Git is overall better than all them *just* because it 
has a non-zero number of advantages over each. You could just as easily flip 
it around and do the same with almost any of them. So it's ultimately 
misleading and unhelpful.
Nov 03 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 I don't hate Git. I just don't understand the current opinion and would  
 be glad if someone will base is for me, TIA.


Mercurial's biggest problem is how everything is based on extensions (and  
none of them is activated by default!!!).
Even indispensable features like record, rebase and stash. I usually have  
to activate over dozen plugins just to get a base set of tools I need.

Also there's bookmarks to support git like 'lite' branching but it 's a  
PITA to use it as soon as there is more than 1 developer cause everyone  
needs to set it up, then everyone needs to remember that they aren't  
pushed/pulled by default etc.
Anonymous branches are nice in theory but as soon as you publish them and  
accidentally the tip is your anonymous branch everyone who pulls will  
imperceptibly work on that branch and not on the actual master.

Configuring it involves manual editing while git-config provides a nice  
interface including auto-completion and you don't have to worry which file  
it goes to.

The only drawback I experienced is Windoze-specific. There you have  
TortoiseHg which makes work really nice while TortoiseGit lacks behind and  
msysgit is just a pain.
Nov 02 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Trass3r" <un known.com> wrote in message news:op.v4bmzpkb3ncmek enigma...

 The only drawback I experienced is Windoze-specific. There you have 
 TortoiseHg which makes work really nice while TortoiseGit lacks behind and 
 msysgit is just a pain.


I've been using Tortoise* for 90% of my DVCS dealings and I've come to find 
that I like TortoiseGit much better than TortoiseHg (FWIW). I think what 
really tips the scale for me is the "Git Sync..." part (The TortoiseHg 
equivalent isn't nearly as nice, IMO). And the ability to do a push right 
after committing with just one click is really nice, too. Conflict 
resolution with TortoiseHg is a royal PITA. Plus, I haven't figured out how 
to use a client cert with Hg/TortoiseHg in order to not have to type my 
password every single time I push.

I really want a unified Tortoise though (And cross-platform, too, so I won't 
have to give it up when I switch to Linux). It was all fine when SVN was all 
I was using, but now that I have some stuff in Git, some stuff Hg, some 
older stuff that's still SVN ATM, etc, having all that Tortoise crap every 
time I open the right-click menu is a pain, especially since I can never 
remember immediately (ie, without thinking about it) which project is using 
which.

I've come to like BitBucket *far* better than GitHub though, so I was 
thrilled when I found out that BitBucket added Git support. Seriously, if 
one of the main points of Git is speed, then why the hell is GitHub so 
insanely slow? ('Course, I have other issues with GitHub, too.) Not that 
BitBucket is exactly zippy either, but it's fast compared to GitHub. Now 
Launchpad - that's one I *really* wish had a half-way decent interface 
because it's the only one that has proper speed. Plus it's also the only one 
that doesn't try to cram any of that Ajaxy bullshit down everyone's throat 
(Another thing GitHub is even worse with than BitBucket. Really, every time 
GitHub makes an update, it breaks more and more shit).

'Course that all leads to another thing: Why can't all this collaboration 
stuff just be part of the DVCS itself (or at least a standard plugin)? 
That's what really bugs me. Crappy web interfaces aside, 
GitHub/BitBucket/Launchpad functionality is fantastic...BUT, just because 
they've all gone and done it *outside* of the actual DVCSes, *none* of their 
functionality actually works across repository hosts (and making that happen 
on a large, properly generalized, scale would be impractical). It also makes 
it that much harder for anyone to create alternate interfaces - you'd have 
to create a whole new backend for every damn host, not just one for each 
DVCS. And all of that creates a situation which forces any alternative hosts 
(for example, self-hosted ones) to be completely SOL right out of the gate 
(And you can't tell me GitHub, being a commercial entity, doesn't *want* 
things to be this way). The whole current approach just doesn't make any 
damn sense at all. But that's the moronic "cloud" culture for ya.
Nov 02 2011
parent reply Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:


 'Course that all leads to another thing: Why can't all this collaboration 
 stuff just be part of the DVCS itself (or at least a standard plugin)? 
 That's what really bugs me. Crappy web interfaces aside, 
 GitHub/BitBucket/Launchpad functionality is fantastic...BUT, just because 
 they've all gone and done it *outside* of the actual DVCSes, *none* of their 
 functionality actually works across repository hosts (and making that happen 
 on a large, properly generalized, scale would be impractical). It also makes 
 it that much harder for anyone to create alternate interfaces - you'd have 
 to create a whole new backend for every damn host, not just one for each 
 DVCS.


Did you hear about Fossil? It hosts SQLite sources.
Nov 02 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 02-11-2011 16:28, Kagamin wrote:

 Nick Sabalausky Wrote:


 'Course that all leads to another thing: Why can't all this collaboration
 stuff just be part of the DVCS itself (or at least a standard plugin)?
 That's what really bugs me. Crappy web interfaces aside,
 GitHub/BitBucket/Launchpad functionality is fantastic...BUT, just because
 they've all gone and done it *outside* of the actual DVCSes, *none* of their
 functionality actually works across repository hosts (and making that happen
 on a large, properly generalized, scale would be impractical). It also makes
 it that much harder for anyone to create alternate interfaces - you'd have
 to create a whole new backend for every damn host, not just one for each
 DVCS.


 Did you hear about Fossil? It hosts SQLite sources.


The only gripe I have with Fossil is the sacred history. Other than 
that, very nice tool!

- Alex
Nov 02 2011
prev sibling parent reply Uno <unodgs tlen.pl> writes:
 The only drawback I experienced is Windoze-specific. There you have
 TortoiseHg which makes work really nice while TortoiseGit lacks behind
 and msysgit is just a pain.


I use SmartGit. Very good tool IMO. 
(http://www.syntevo.com/smartgit/index.html). Current version (3 alpha) 
uses SWT instead of Swing (better UI experience) 
http://www.syntevo.com/smartgit/early-access.html. For personal use it's 
free.
Nov 02 2011
next sibling parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 11/2/2011 1:41 PM, Uno wrote:

 The only drawback I experienced is Windoze-specific. There you have
 TortoiseHg which makes work really nice while TortoiseGit lacks behind
 and msysgit is just a pain.


 I use SmartGit. Very good tool IMO.
 (http://www.syntevo.com/smartgit/index.html). Current version (3 alpha)
 uses SWT instead of Swing (better UI experience)
 http://www.syntevo.com/smartgit/early-access.html. For personal use it's
 free.


Wow, thanks. I'll admit I had gone to SmartGit's site, but as soon as I 
saw the "Purchase" link I immediately closed the window. Good to know 
it's free for personal use!

Yeah, the SWG version is much nicer to look at. I think this just 
replaced TortoiseGit!
Nov 02 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Uno" <unodgs tlen.pl> wrote in message 
news:j8rvda$1nuk$1 digitalmars.com...

 The only drawback I experienced is Windoze-specific. There you have
 TortoiseHg which makes work really nice while TortoiseGit lacks behind
 and msysgit is just a pain.


 I use SmartGit. Very good tool IMO. 
 (http://www.syntevo.com/smartgit/index.html). Current version (3 alpha) 
 uses SWT instead of Swing (better UI experience) 
 http://www.syntevo.com/smartgit/early-access.html. For personal use it's 
 free.


Doen't seem to run at all for me. No UI at all, and never shows up in task 
manager. 'Course, like you said, it is still just alpha.
Nov 03 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/3/11, Nick Sabalausky <a a.a> wrote:

 "Uno" <unodgs tlen.pl> wrote in message
 news:j8rvda$1nuk$1 digitalmars.com...

 The only drawback I experienced is Windoze-specific. There you have
 TortoiseHg which makes work really nice while TortoiseGit lacks behind
 and msysgit is just a pain.


 I use SmartGit. Very good tool IMO.
 (http://www.syntevo.com/smartgit/index.html). Current version (3 alpha)
 uses SWT instead of Swing (better UI experience)
 http://www.syntevo.com/smartgit/early-access.html. For personal use it's
 free.


 Doen't seem to run at all for me. No UI at all, and never shows up in task
 manager. 'Course, like you said, it is still just alpha.


I've had the same problem, so I've redownloaded the one *with* JRE.
Then it worked.
Nov 03 2011
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Wed, 02 Nov 2011 11:07:54 +0100, Denis Shelomovskij  =

<verylonglogin.reg gmail.com> wrote:


 02.11.2011 8:23, Caligo =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 I just found out that Bitbucket finally offers Git support.  I wonder=




,

 would anyone else like to see GDC switch to Git?  I would like to kin=




dly

 make a request because it would make things little easier.


 What things? I see, that every one switches to Git, but what the  =



 purpose? I don't have a deep knowledge about DVCS-s, but I'm really  =



 interested in what Git functionality is missing in Hg for you?

 Is it:
 * discarding previously pulled branches;
 * pruning old revision data from the local repository;
 * unlimited number of parent revisions during a merge;
 * rebasing;
 * infinite power of `git-push --force`?

 Only the first one looks good for me, but the last one scares me becau=


se  =


 you can loose the remote repository (and I really sow it frightens  =



 people). Others are looking seldom applicable.

 So why does Git advantages worth:
 * Git complexity (in comparison with Hg);
 * ability to loose the remote repository;
 * lack of file rename/copy support;
 * periodic maintenance with git-gc?


 I don't hate Git. I just don't understand the current opinion and woul=


d  =


 be glad if someone will base is for me, TIA.


The main point is that git offers a lean mental model.

http://book.git-scm.com/1_the_git_object_model.html
http://book.git-scm.com/7_the_packfile.html

IMHO a complete understanding/control of what is happening scales much  =

better
than a fleshed out abstraction that hangs in the air.

Two regular arguments against git.

- The Tcl/Tk based Git Gui and gitk look awful.

   Yes the do but are highly efficient on a day-to-day basis.
   I'm running a FreeBSD system and I can not find any simple
   (non-KDE) but complete Hg tool.
   Complete here means committing and inspecting the tree.
   On windows you have TortoiseHg which already is too fancy.


- I don't want to be able to delete my commits.

   Yes you do. Way more often than expected. Git helps a lot
   in organizing experimental changes/committing. Also git
   does not delete commits but uses garbage collection, you can
   get them back from the trashcan. You can also create hazard
   references and delete them.

That said it takes a while.

martin
Nov 02 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Martin Nowak" <dawg dawgfoto.de> wrote in message 
news:mailman.631.1320245247.24802.digitalmars-d puremagic.com...

The main point is that git offers a lean mental model.

http://book.git-scm.com/1_the_git_object_model.html
http://book.git-scm.com/7_the_packfile.html

IMHO a complete understanding/control of what is happening scales much 
better
than a fleshed out abstraction that hangs in the air.


OTOH, Git pretty much expects you to understand that under-the-hood stuff 
for any of it to even make sense in the first place ("hard, soft, hard and 
soft, index, blah, blah, blah, WTF just undo the gorram commit, damnnit!"). 
Hg you can pretty much just pick up and go.
Nov 02 2011
parent reply Jose Armando Garcia <jsancio gmail.com> writes:
On Wed, Nov 2, 2011 at 8:19 AM, Nick Sabalausky <a a.a> wrote:

 "Martin Nowak" <dawg dawgfoto.de> wrote in message
 news:mailman.631.1320245247.24802.digitalmars-d puremagic.com...

The main point is that git offers a lean mental model.

http://book.git-scm.com/1_the_git_object_model.html
http://book.git-scm.com/7_the_packfile.html

IMHO a complete understanding/control of what is happening scales much
better
than a fleshed out abstraction that hangs in the air.


 OTOH, Git pretty much expects you to understand that under-the-hood stuff
 for any of it to even make sense in the first place ("hard, soft, hard and
 soft, index, blah, blah, blah, WTF just undo the gorram commit, damnnit!").
 Hg you can pretty much just pick up and go.


Thats like trying to successfully write an application that uses an
SQL database application without knowing SQL, database theory, etc.

Thats like trying to successfully write a networked application
without knowing how IP, TCP, UDP, etc work.

Thats like trying to successfully write a D program without knowing
how the language works.

Thats like trying to successfully write a computer software without
knowing how a computer works.
Nov 02 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jose Armando Garcia" <jsancio gmail.com> wrote in message 
news:mailman.635.1320260049.24802.digitalmars-d puremagic.com...

 On Wed, Nov 2, 2011 at 8:19 AM, Nick Sabalausky <a a.a> wrote:

 "Martin Nowak" <dawg dawgfoto.de> wrote in message
 news:mailman.631.1320245247.24802.digitalmars-d puremagic.com...

The main point is that git offers a lean mental model.

http://book.git-scm.com/1_the_git_object_model.html
http://book.git-scm.com/7_the_packfile.html

IMHO a complete understanding/control of what is happening scales much
better
than a fleshed out abstraction that hangs in the air.


 OTOH, Git pretty much expects you to understand that under-the-hood stuff
 for any of it to even make sense in the first place ("hard, soft, hard 
 and
 soft, index, blah, blah, blah, WTF just undo the gorram commit, 
 damnnit!").
 Hg you can pretty much just pick up and go.


 Thats like trying to successfully write an application that uses an
 SQL database application without knowing SQL, database theory, etc.

 Thats like trying to successfully write a networked application
 without knowing how IP, TCP, UDP, etc work.

 Thats like trying to successfully write a D program without knowing
 how the language works.

 Thats like trying to successfully write a computer software without
 knowing how a computer works.


Bad analogies: You shouldn't have to know how IP, TCP, UDP, etc work to 
successfully *USE* a networked application. Etc... I'm not talking about 
contributing to the Git/Hg projects themselves, I'm talking about just 
simply *using* them.
Nov 02 2011
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Jose Armando Garcia wrote:

 On Wed, Nov 2, 2011 at 8:19 AM, Nick Sabalausky <a a.a> wrote:

 "Martin Nowak" <dawg dawgfoto.de> wrote in message
 news:mailman.631.1320245247.24802.digitalmars-d puremagic.com...

 The main point is that git offers a lean mental model.

 http://book.git-scm.com/1_the_git_object_model.html
 http://book.git-scm.com/7_the_packfile.html

 IMHO a complete understanding/control of what is happening scales muc=






h

 better
 than a fleshed out abstraction that hangs in the air.


 OTOH, Git pretty much expects you to understand that under-the-hood st=




uff

 for any of it to even make sense in the first place ("hard, soft, hard=




 and

 soft, index, blah, blah, blah, WTF just undo the gorram commit, damnni=




t!").

 Hg you can pretty much just pick up and go.


=20
 Thats like trying to successfully write an application that uses an
 SQL database application without knowing SQL, database theory, etc.
=20
 Thats like trying to successfully write a networked application
 without knowing how IP, TCP, UDP, etc work.
=20
 Thats like trying to successfully write a D program without knowing
 how the language works.
=20
 Thats like trying to successfully write a computer software without
 knowing how a computer works.


	That's like not knowing how IP, TCP, UDP, etc work to use a web
browser...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Nov 02 2011
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
On Thu, Nov 3, 2011 at 12:47 AM, Martin Nowak <dawg dawgfoto.de> wrote:


 On Wed, 02 Nov 2011 11:07:54 +0100, Denis Shelomovskij <
 verylonglogin.reg gmail.com> wrote:

 Two regular arguments against git.

 - The Tcl/Tk based Git Gui and gitk look awful.

  Yes the do but are highly efficient on a day-to-day basis.
  I'm running a FreeBSD system and I can not find any simple
  (non-KDE) but complete Hg tool.
  Complete here means committing and inspecting the tree.
  On windows you have TortoiseHg which already is too fancy.\


 It's a pity you specify non-kde. However so far I have found git-cola my
favourite git front end and KDevelops built in git support is starting to
get good. Git Cola I think is Qt but with no KDE dependencies.

We are about to trial git-cola and git on our windows workstations for our
artists (they are currently using subversion and tortoise-svn - but have a
lot of slowdowns due to our artists committing assets but forgetting to
commit other assets that those assets refer to).
Nov 02 2011
prev sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Wed, 02 Nov 2011 21:24:53 +0100, Danni Coy <danni.coy gmail.com> wrote:


 On Thu, Nov 3, 2011 at 12:47 AM, Martin Nowak <dawg dawgfoto.de> wrote:


 On Wed, 02 Nov 2011 11:07:54 +0100, Denis Shelomovskij <
 verylonglogin.reg gmail.com> wrote:

 Two regular arguments against git.

 - The Tcl/Tk based Git Gui and gitk look awful.

  Yes the do but are highly efficient on a day-to-day basis.
  I'm running a FreeBSD system and I can not find any simple
  (non-KDE) but complete Hg tool.
  Complete here means committing and inspecting the tree.
  On windows you have TortoiseHg which already is too fancy.\


  It's a pity you specify non-kde. However so far I have found git-cola my
 favourite git front end and KDevelops built in git support is starting to
 get good. Git Cola I think is Qt but with no KDE dependencies.

 We are about to trial git-cola and git on our windows workstations for  
 our
 artists (they are currently using subversion and tortoise-svn - but have  
 a
 lot of slowdowns due to our artists committing assets but forgetting to
 commit other assets that those assets refer to).


I don't have issues finding a program for git but one for hg.
Looks nice though, especially the DAG reminds me of an idea
I have in mind which I never got round to program.

Setting-up Git on Windows can be a mildly PITA, so I wish you good luck.
There's a commercial tool http://www.syntevo.com/smartgit/index.html
that some people like but IMHO it's too Java.

martin
Nov 03 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 03-11-2011 18:45, Martin Nowak wrote:

 On Wed, 02 Nov 2011 21:24:53 +0100, Danni Coy <danni.coy gmail.com> wrote:


 On Thu, Nov 3, 2011 at 12:47 AM, Martin Nowak <dawg dawgfoto.de> wrote:


 On Wed, 02 Nov 2011 11:07:54 +0100, Denis Shelomovskij <
 verylonglogin.reg gmail.com> wrote:

 Two regular arguments against git.

 - The Tcl/Tk based Git Gui and gitk look awful.

 Yes the do but are highly efficient on a day-to-day basis.
 I'm running a FreeBSD system and I can not find any simple
 (non-KDE) but complete Hg tool.
 Complete here means committing and inspecting the tree.
 On windows you have TortoiseHg which already is too fancy.\


 It's a pity you specify non-kde. However so far I have found git-cola my
 favourite git front end and KDevelops built in git support is starting to
 get good. Git Cola I think is Qt but with no KDE dependencies.

 We are about to trial git-cola and git on our windows workstations for
 our
 artists (they are currently using subversion and tortoise-svn - but
 have a
 lot of slowdowns due to our artists committing assets but forgetting to
 commit other assets that those assets refer to).


 I don't have issues finding a program for git but one for hg.
 Looks nice though, especially the DAG reminds me of an idea
 I have in mind which I never got round to program.

 Setting-up Git on Windows can be a mildly PITA, so I wish you good luck.
 There's a commercial tool http://www.syntevo.com/smartgit/index.html
 that some people like but IMHO it's too Java.

 martin


msysgit has always worked great on Windows for me.

- Alex
Nov 03 2011
prev sibling parent Trass3r <un known.com> writes:
Am 02.11.2011, 06:23 Uhr, schrieb Caligo <iteronvexor gmail.com>:


 I just found out that Bitbucket finally offers Git support.  I wonder,
 would anyone else like to see GDC switch to Git?  I would like to kindly
 make a request because it would make things little easier.


If they switch they should move to GitHub as well.
Nov 02 2011