Werner Smekal writes:
> I often commit "unfinished" work for only one reason - not to loose it.
> My laptop is old, the harddisk may get corrupt. I often spend some hours
> work and don't want to loose it. With git I can commit more often to my
> local repository which is fine. But if my laptop breaks these changes
> are also lost. You are talking about being adventurous and doing
> explanatory work - but are these changes only commited on my local
> (laptop) repository or also to the master repo (not being visible to
> others)?
Well, either is possible. Personally I would like to avoid pushing things
into the project master repo until they're "ready". So if I were trying to
have a backup, as you describe, what I would suggest would be to set up
another git repo on another physical machine, and push my intermediate work
to that repo. With suitable configuration, you could say "git push backup",
where backup was a git id for a network accessible repo on another machine.
If you said "git push origin", which is the same as saying "git push", then
your commits would be propagated to the project master repo. If those
changes were on a branch, then you would be updating the branch in the
project master repo, with your incremental work. That would be better
(meaning, lower impact on others), than pushing intermediate work in on
trunk/master, but it still represents pushing things into the project master
repo, when all you're really trying to do is achieve some redundancy as a
guard against system failure.
In my opinion, better to define "backup" as a git alias for some machine you
control, network accessible to you, in your home or office network, and then
use "git push backup" as a way to do this sort of safety-net stuff.
Bottom line, git provides more, and more sophisticated options for
collaboration (which can also mean, ways of collaborating with yourself), and
these can avoid going through the project master. To me, this is a very big
benefit. But, bottom line, git does not enforce a limited set of options.
It's more like the superlative tool for SCM, and leaves it to you how you
want to use it.
> Apart from that: I personally wouldn't mind using git for PLplot
> development as I already use Mercury (only for local revisioned backups)
> and I think what you said makes sense. BUT: the last time I checked was
> the Windows support of git not there where it should be. A long time
> only a cygwin port of git was available which was practically useless if
> you really want to work on Windows. An although I really prefer to code
> in Linux or Mac OS X over then in Windows, I really think that it is
> important to have a Windows port of PLplot. That was also one reason why
> I turned away immediately when I checked git. Looks fine, but no
> useful Windows port? Sorry, nowadays writing cross platform code for
> such projects as git is should be standard.
>
> I just checked, there is now MSysGit and TortoiseGit but one can read
> between the lines (" although Git works very well (better, actually) on
> Linux or Mac. ") that it is still not there. I actually don't like it
> much to code in Windows (although it's 70% of my PLplot coding time),
> but making my life worse here doesn't help too much. So we really should
> make tests on Windows thoroughly if MsysGit is of any use in Windows.
>
> So in my opinion I wouldn't mind change to git, many of the things you
> said sounds good. But for me personally I would like to have a decent
> Windows port first (which may be here already) to make the transition to
> git also easy for the people who need to work in Windows.
I understand, and agree. It is obvious that the Windows work is important to
PLplot. So I also would want to hear that our various team members who work
regularly on windows, have a git option which is acceptable to them.
I personally do not touch windows. [<sheepish smirk> I should write a book
someday, about what happens to corporate IT admins who try to force me to use
windows.] I keep telling myself I should set up a cross tool chain on my
Linux boxes, and practice running cross-tool builds through Wine. But I
never get around to it.
Nevertheless, my personal habits are obviously not representative of the
whole PLplot team. So I do agree and believe, that we would need agreement
from those PLplot core developers who do do development on Windows, that the
git situation has reached an acceptable state for them. I can't contribute
to that evaluation, except to answer questions about how git works, which I
am happy to do.
--
Geoff
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
