www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - BitBucket Offers Git Support

reply Caligo <iteronvexor gmail.com> writes:
--20cf307f363068498604b0b9ac95
Content-Type: text/plain; charset=ISO-8859-1

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.

--20cf307f363068498604b0b9ac95
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

--20cf307f363068498604b0b9ac95--
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 Rnne 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 next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=

 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:
""Jrme 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 "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 "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 next 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.

(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.

(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 "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.

(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
prev sibling next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=



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



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


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


 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. =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 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 next sibling parent 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
prev sibling next 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
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=


 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=

 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=

 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 "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
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
--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.

--bcaec5196a6589aea504b0c47177
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This wasn&#39;t supposed to be about Git vs Mercurial. =A0I should have bee=
n more clear in my post!<div><br></div><div>The reason it would make things=
 easier if we switched to using Git on Bitbucket is because it would make t=
hings more streamlined. =A0I don&#39;t like how I need to use Mercurial whe=
n I want to work on GDC, then switch back to Git when working on DMD. =A0It=
 would even be better if both projects were using the same hosting site.</d=
iv>

--bcaec5196a6589aea504b0c47177--
Nov 02 2011
prev sibling next sibling 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
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 next sibling parent Danni Coy <danni.coy gmail.com> writes:
--f46d044471e5c8421104b0c6432e
Content-Type: text/plain; charset=ISO-8859-1

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). --f46d044471e5c8421104b0c6432e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Nov 3, 2011 at 12:47 AM, Martin = Nowak <span dir=3D"ltr">&lt;<a href=3D"mailto:dawg dawgfoto.de">dawg dawgfo= to.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"HOEnZb"><div class=3D"h5">On Wed, 02 Nov 2011 11:07:54 +0100,= Denis Shelomovskij &lt;<a href=3D"mailto:verylonglogin.reg gmail.com" targ= et=3D"_blank">verylonglogin.reg gmail.com</a>&gt; wrote:<br></div></div> <br> Two regular arguments against git.<br> <br> - The Tcl/Tk based Git Gui and gitk look awful.<br> <br> =A0Yes the do but are highly efficient on a day-to-day basis.<br> =A0I&#39;m running a FreeBSD system and I can not find any simple<br> =A0(non-KDE) but complete Hg tool.<br> =A0Complete here means committing and inspecting the tree.<br> =A0On windows you have TortoiseHg which already is too fancy.\<br></blockq= uote><div><br></div><div>=A0It&#39;s a pity you specify non-kde. However so= far I have found git-cola my favourite git front end and KDevelops built i= n git support is starting to get good. Git Cola I think is Qt but with no K= DE dependencies.</div> <div><br></div><div>We are about to trial git-cola and git on our windows w= orkstations for our artists (they are currently using subversion and tortoi= se-svn - but have a lot of slowdowns due to our artists=A0committing=A0asse= ts but forgetting to commit other assets that those assets refer to).</div> <div><br></div><div><br></div></div> --f46d044471e5c8421104b0c6432e--
Nov 02 2011
prev sibling next sibling parent "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
prev sibling next sibling 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.

(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 parent "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