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.
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
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
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
Am 02.11.2011, 06:23 Uhr, schrieb 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.
If they switch they should move to GitHub as wel
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
On Wed, 02 Nov 2011 11:07:54 +0100, 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 easi
"Trass3r" 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'
"Martin Nowak" wrote in message
news:mailman.631.1320245247.24802.digitalmar...@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 o
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, j
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
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. Reba
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 functio
> > 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
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,
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
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 S
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 b
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
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 connecte
On Wed, Nov 2, 2011 at 8:19 AM, Nick Sabalausky wrote:
> "Martin Nowak" wrote in message
> news:mailman.631.1320245247.24802.digitalmar...@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.co
On Thu, Nov 3, 2011 at 12:47 AM, Martin Nowak wrote:
> On Wed, 02 Nov 2011 11:07:54 +0100, Denis Shelomovskij <
> verylonglogin@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
"Jose Armando Garcia" wrote in message
news:mailman.635.1320260049.24802.digitalmar...@puremagic.com...
> On Wed, Nov 2, 2011 at 8:19 AM, Nick Sabalausky wrote:
>> "Martin Nowak" wrote in message
>> news:mailman.631.1320245247.24802.digitalmar...@puremagic.com...
>>>
>>>The main point is that g
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.
Caligo wrote:
> 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
Jose Armando Garcia wrote:
> On Wed, Nov 2, 2011 at 8:19 AM, Nick Sabalausky wrote:
>> "Martin Nowak" wrote in message
>> news:mailman.631.1320245247.24802.digitalmar...@puremagic.com...
>>> The main point is that git offers a lean mental model.
>>>
>>> http://book.git-scm.com/1_the_git_object_mo
== Quote from Caligo (iteronve...@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 G
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 versio
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 w
On Thu, 03 Nov 2011 03:24:51 +0200, Don 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.
--
Bes
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.
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. :)
""Jérôme M. Berger"" 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 pr
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 rem
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 tryi
"Vladimir Panteleev" wrote in message
news:op.v4ckapeytuz...@cybershadow.mshome.net...
> On Thu, 03 Nov 2011 03:24:51 +0200, Don 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
"Uno" 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.synt
> > 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 *leas
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
On 11/3/11, Nick Sabalausky wrote:
> "Uno" 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 SmartG
On Wed, 02 Nov 2011 21:24:53 +0100, Danni Coy wrote:
On Thu, Nov 3, 2011 at 12:47 AM, Martin Nowak wrote:
On Wed, 02 Nov 2011 11:07:54 +0100, Denis Shelomovskij <
verylonglogin@gmail.com> wrote:
Two regular arguments against git.
- The Tcl/Tk based Git Gui and gitk look awful.
Yes th
On 03-11-2011 18:45, Martin Nowak wrote:
On Wed, 02 Nov 2011 21:24:53 +0100, Danni Coy wrote:
On Thu, Nov 3, 2011 at 12:47 AM, Martin Nowak wrote:
On Wed, 02 Nov 2011 11:07:54 +0100, Denis Shelomovskij <
verylonglogin@gmail.com> wrote:
Two regular arguments against git.
- The Tcl/Tk b
42 matches
Mail list logo
