Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #77503 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2015-12-01 12:52 +0000 |
| Last post | 2015-12-01 12:24 -0800 |
| Articles | 20 on this page of 151 — 24 participants |
Back to article view | Back to comp.lang.c
// comments and \ BartC <bc@freeuk.com> - 2015-12-01 12:52 +0000
Re: // comments and \ me <self@example.org> - 2015-12-01 13:08 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 08:20 -0500
Re: // comments and \ me <self@example.org> - 2015-12-01 13:36 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 09:03 -0500
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 14:14 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 07:40 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 08:55 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 17:15 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 09:58 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:11 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 10:18 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:20 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 11:07 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 11:39 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 12:33 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:05 +0000
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:30 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 20:59 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-01 15:22 -0500
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:37 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 14:56 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 22:11 +0100
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:01 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 00:45 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 15:19 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 08:29 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:35 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 09:21 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 16:41 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 10:15 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:24 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:43 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:05 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-02 11:40 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:29 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 19:11 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 20:43 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 21:04 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 21:16 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:12 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 11:52 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:40 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 13:55 +0100
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 13:56 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 15:24 +0100
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 06:54 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 16:40 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 18:24 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-02 20:27 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 23:22 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 00:57 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:44 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 21:17 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 00:43 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:32 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 16:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:10 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:18 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-06 14:26 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 12:45 +0100
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:45 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-04 04:20 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:20 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 10:05 -0500
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 17:31 +0100
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 17:24 -0600
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 18:50 -0500
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:34 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-10 20:40 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-04 09:36 -0800
Re: // comments and \ Richard Damon <Richard@Damon-Family.org> - 2015-12-05 09:05 -0500
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 17:42 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-06 22:23 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-07 21:59 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 15:50 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-05 18:17 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:01 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 03:05 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 04:07 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 04:37 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 05:05 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:19 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 13:59 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 06:09 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 07:30 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 18:55 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:23 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:22 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 21:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:14 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:09 +0000
Re: // comments and \ mark.bluemel@gmail.com - 2015-12-03 06:15 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-02 08:28 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 09:01 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 21:52 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 16:55 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 13:11 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:21 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 11:22 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 01:12 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:39 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:14 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-04 12:25 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:23 +0100
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:00 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:46 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:36 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 20:37 -0700
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:26 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 14:32 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:52 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 16:15 +0100
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:28 +0000
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:12 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:17 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 12:32 -0600
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 00:01 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 07:08 -0800
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 21:05 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 14:22 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 14:48 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 23:37 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 17:10 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 19:24 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-03 04:10 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:49 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-03 07:28 -0700
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 09:12 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 06:53 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 15:41 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 15:56 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 16:44 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 17:29 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 19:10 -0800
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:59 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:21 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:50 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:49 -0800
Re: // comments and \ Geoff <geoff@invalid.invalid> - 2015-12-01 11:34 -0800
Re: // comments and \ David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:44 -0500
Re: // comments and \ "Charles Richmond" <numerist@aquaporin4.com> - 2015-12-23 14:35 -0600
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 13:00 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:58 -0500
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 14:21 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:55 -0500
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-01 12:24 -0800
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-01 21:16 +0000 |
| Message-ID | <slrnn5s3h2.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77571 |
On Tue, 2015-12-01, BartC wrote: > On 01/12/2015 20:43, Jorgen Grahn wrote: ... >> Or often better, use the version control system and just delete the >> code. > > Better? I comment and uncomment lines /all the time/ while developing > code, sometimes several times a minute. I use single-key commands in my ... > (I've never used version control but it sounds like [...] Then you should really, /really/ start now. It's the best way to improve your work, in any language. Or for that matter if you're writing documents. (I can recommend Git. I've used other tools for almost a quarter of a century, but Git (and maybe other newcomers) are drastically better.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-12-02 03:12 -0800 |
| Message-ID | <MPG.30c87207646df0d3ba@news.eternal-september.org> |
| In reply to | #77571 |
BartC wrote: > Jorgen Grahn wrote: > > Richard Heathfield wrote: > >> Joe Pfeiffer wrote: > >>> > >>> I like [ // comments ] for two reasons -- > >>> > >>> I don't have to look for the end of a comment block. It's just a block > >>> of // > >> > >> Syntax colouring? :-) > >> > >>> > >>> If I'm in the throes of debugging I can comment out a bunch of code with > >>> /* */ without a comment throwing in a monkey wrench. > >> > >> #if 0 > >> > >> #endif > > > > Or often better, use the version control system and just delete the > > code. > > Better? I comment and uncomment lines /all the time/ while developing > code, sometimes several times a minute. I use single-key commands in my > editor to instantly comment/uncomment the current line then move on to > the next. With key repeat it can do blocks of code at 20 lines per > second. Commented blocks can be nested. > > I can compare commented/uncommented lines instantly. One common use is > to comment out the real code and use temporary test code to try > something new; I don't want to delete working code! > > How long would a version system take to do that with trivial blocks of > code? Apart which which, I might in the middle move on to work on > another part of the application, then come back to this bit. How to undo > the obvious comments without undoing anything else? > > (I've never used version control but it sounds like a very big > sledgehammer to for what we're talking about. Using #if 0 is just a > standard hammer for the same job!) It is a big hammer for this kind of job, but if you are using it anyway for the things that it is needed for (which I highly recommend), it is there ready and waiting to do these sorts of tasks also. Git can do all the things you mention above in an instant (once you learn the commands, of course). And you never need to worry about deleting working code, either accidentally or because you thought you discovered a better way and then changed your mind later. It's always there in the git repository (assuming you commit frequently enough).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-02 11:52 +0000 |
| Message-ID | <n3mltr$6ti$1@dont-email.me> |
| In reply to | #77603 |
On 02/12/2015 11:12, Philip Lantz wrote: > BartC wrote: >> Jorgen Grahn wrote: >>> Or often better, use the version control system and just delete the >>> code. >> >> Better? I comment and uncomment lines /all the time/ while developing >> code, sometimes several times a minute. ... >> (I've never used version control but it sounds like a very big >> sledgehammer to for what we're talking about. > It is a big hammer for this kind of job, but if you are using it > anyway for the things that it is needed for (which I highly > recommend), it is there ready and waiting to do these sorts of > tasks also. > > Git can do all the things you mention above in an instant (once you > learn the commands, of course). Thanks, but I prefer using my own tools as I've always have done. But reading through the Wikipedia entry for Git made my head spin, and I'm still none the wiser as to exactly what it is or how it works, or whether it would need an internet connection to work. (Does it provide and editor and IDE, or are those separate? Does it work mainly for C?) It doesn't look like it has particularly small footprint either: "Installing Git under Windows creates a similarly named Program Files directory containing 5,236 files in 580 directories. These include the MinGW port of the GNU Compiler Collection, Perl 5, msys2.0, itself a fork of Cygwin, a Unix-like emulation environment for Windows, and various other Windows ports or emulations of Linux utilities and libraries. Currently there is no native port of Git for Windows." My own editor is a single 64KB file (ie. 0.064MB). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-02 04:40 -0800 |
| Message-ID | <ff728456-ab8d-4465-beeb-b99001fb1020@googlegroups.com> |
| In reply to | #77605 |
On Wednesday, December 2, 2015 at 11:52:58 AM UTC, Bart wrote: > > But reading through the Wikipedia entry for Git made my head spin, and > I'm still none the wiser as to exactly what it is or how it works, or > whether it would need an internet connection to work. (Does it provide > and editor and IDE, or are those separate? Does it work mainly for C?) > > It doesn't look like it has particularly small footprint either: > There's inherently no good way of managing multiple programmer maintaining multi-file programs and allowing distribution. But git has emerged as the winner. It's basically commandline, which means it works the same anywhere (on Windows it comes with its own little command prompt. People have written graphical front ends for it. It's pretty confusing at first because it uses a 'stage". You edit a file, and of course git keeps a copy of the previous version and tags the fact it has been edited. But to submit the change, you need to first stage the edit, then commit. So that makes it easier to abandon abortive edits, but it also means that it's easy for a novice user to edit a file, not stage it, commit, and thus create what he thinks is a functioning version but is in fact broken. Then there's the further stage which is "push". > > "Installing Git under Windows creates a similarly named Program Files > directory containing 5,236 files in 580 directories. These include the > MinGW port of the GNU Compiler Collection, Perl 5, msys2.0, itself a > fork of Cygwin, a Unix-like emulation environment for Windows, and > various other Windows ports or emulations of Linux utilities and > libraries. Currently there is no native port of Git for Windows." > > My own editor is a single 64KB file (ie. 0.064MB). > it installs the cygwin infrastructure, mainly as an act of spite against Microsoft. It could run perfectly happily in a DOS shell or as a gui app. (If they want my Baby X system, it has a console widget, and it can then port to either Windows or Linux).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-02 13:55 +0100 |
| Message-ID | <n3mpk4$knk$1@dont-email.me> |
| In reply to | #77605 |
On 02/12/15 12:52, BartC wrote: > On 02/12/2015 11:12, Philip Lantz wrote: >> BartC wrote: >>> Jorgen Grahn wrote: > >>>> Or often better, use the version control system and just delete the >>>> code. >>> >>> Better? I comment and uncomment lines /all the time/ while developing >>> code, sometimes several times a minute. ... > >>> (I've never used version control but it sounds like a very big >>> sledgehammer to for what we're talking about. > >> It is a big hammer for this kind of job, but if you are using it >> anyway for the things that it is needed for (which I highly >> recommend), it is there ready and waiting to do these sorts of >> tasks also. >> >> Git can do all the things you mention above in an instant (once you >> learn the commands, of course). > > Thanks, but I prefer using my own tools as I've always have done. > > But reading through the Wikipedia entry for Git made my head spin, and > I'm still none the wiser as to exactly what it is or how it works, or > whether it would need an internet connection to work. (Does it provide > and editor and IDE, or are those separate? Does it work mainly for C?) Read this one first: <https://en.wikipedia.org/wiki/Version_control> Without an understanding of version control or version control systems, you are not going to get a handle on git. > > It doesn't look like it has particularly small footprint either: > > "Installing Git under Windows creates a similarly named Program Files > directory containing 5,236 files in 580 directories. These include the > MinGW port of the GNU Compiler Collection, Perl 5, msys2.0, itself a > fork of Cygwin, a Unix-like emulation environment for Windows, and > various other Windows ports or emulations of Linux utilities and > libraries. Currently there is no native port of Git for Windows." Git has quite a small footprint, but it is written in C, perl and a few other utilities. If you are using an OS without perl or such utilities, you need them too - and that means a /lot/ more downloads and installation. So installation of git on a Linux system is probably just a few 10K's - but it is a thousand times as much on a bare windows system. (And yes, unlike all the other utilities you /think/ are Linux only, such as "make", git really is targeted at Linux - it was written originally by Linus Torvalds for tracking the source code of the Linux kernel. But a great many others have found it useful for all sorts of other projects.) If you want to use git on Windows, get TortoiseGit: <https://tortoisegit.org/> As well as the command-line interface, it has a neat gui interface integrated in windows explorer. Even if you are not allergic to the command line (as most Windows users are), the integration with explorer makes many tasks far easier and clearer. However, for someone new to version control systems, especially a Windows user, I would not recommend git. I would suggest subversion (with TortoiseSvn for windows). Git is significantly more powerful - but also significantly more complex. Compared to having a bunch of files in a directory, subversion gives you an extra dimension - it lets you track changes over time. Git gives you two extra dimensions - time, and also branches. So with a view to learning to walk before you try to run, and because walking is often perfectly sufficient and a big improvement over standing still, I suggest you learn about subversion. And since subversion has always been a cross-platform solution from its conception, it does not feel as alien on Windows. > > My own editor is a single 64KB file (ie. 0.064MB). > Git has nothing to do with editors, or IDEs. You need a network connection if you are connecting to a server over a network.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-02 13:56 +0000 |
| Message-ID | <n3mt6p$2n3$1@dont-email.me> |
| In reply to | #77613 |
On 02/12/2015 12:55, David Brown wrote:
> On 02/12/15 12:52, BartC wrote:
>> On 02/12/2015 11:12, Philip Lantz wrote:
>> My own editor is a single 64KB file (ie. 0.064MB).
> Git has nothing to do with editors, or IDEs. You need a network
> connection if you are connecting to a server over a network.
But Philip Lantz said: "Git can do all the things you mention above in
an instant". One thing I mentioned is a single key press to
comment/de-comment, which necessarily has to be done while editing.
So, to give one of innumerable examples, if I normally keep a couple of
guard lines like this:
//puts("ZPOPF1");
pc_udupl(a);
//puts("ZPOPF2");
more-or-less permanently commented so that I can instantly switch them
in when a problem comes up, how exactly is Git going to help here? On my
editor I press Alt-0 three times to de-comment the lines.
Another (made up) example, I have this line:
fn(a->strptr, b->length, FLAG_1 || FLAG_2);
but as an experiment or test, I temporarily want to set parameter #3 to 0:
// fn(a->strptr, b->length, FLAG_1 || FLAG_2);
fn(a->strptr, b->length, 0);
In my editor, that's 4 key-presses (not including making the edit),
although I'm always thinking of making that one key-press as it's such a
common pattern. (Currently it's Alt-D, Up, Alt-1, then Down to get onto
the new line.)
Then, it's just two key-presses to swap the comments between the lines
(Alt-0 then Alt-1 once positioned on the first). I don't want either
line to disappear from view, even temporarily!
I would really like to know how a separate command line utility is going
to be help make such changes as effortlessly as above.
I can't see #if 0 being much help either. How would it work on the first
example:
#if 0
puts("ZPOPF1");
#endif
pc_udupl(a);
#if 0
puts("ZPOPF2");
#endif
Then I change the 0s to 1s? It's hard to figure out what's conditional
and what isn't.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-02 15:24 +0100 |
| Message-ID | <n3muqn$9cq$1@dont-email.me> |
| In reply to | #77615 |
On 02/12/15 14:56, BartC wrote:
> On 02/12/2015 12:55, David Brown wrote:
>> On 02/12/15 12:52, BartC wrote:
>>> On 02/12/2015 11:12, Philip Lantz wrote:
>
>>> My own editor is a single 64KB file (ie. 0.064MB).
>
>> Git has nothing to do with editors, or IDEs. You need a network
>> connection if you are connecting to a server over a network.
>
> But Philip Lantz said: "Git can do all the things you mention above in
> an instant". One thing I mentioned is a single key press to
> comment/de-comment, which necessarily has to be done while editing.
>
> So, to give one of innumerable examples, if I normally keep a couple of
> guard lines like this:
>
> //puts("ZPOPF1");
> pc_udupl(a);
> //puts("ZPOPF2");
>
> more-or-less permanently commented so that I can instantly switch them
> in when a problem comes up, how exactly is Git going to help here? On my
> editor I press Alt-0 three times to de-comment the lines.
>
Don't take people so literally!
What Philip was referring to, I think, is commenting out blocks of code
that are no longer useful, but are kept as comments (or #if'ed out) just
in case someone needs to refer to them in the future.
Typical cases would look like this:
#if 0
// Old version
int foo(int x) {
...
}
#endif
// New version
int foo(int x) {
...
}
People keep such disabled code lying around, because they might want to
copy bits of it, or maybe they worry that there will be bugs in the new
version and they have to go back to the old version.
Using a version control system, you /replace/ the old version with the
new one, and check it in with an appropriate comment. If you ever need
to refer to the old version, it's still there on the version control
server and can be recovered and view as needed.
> Another (made up) example, I have this line:
>
> fn(a->strptr, b->length, FLAG_1 || FLAG_2);
>
> but as an experiment or test, I temporarily want to set parameter #3 to 0:
>
> // fn(a->strptr, b->length, FLAG_1 || FLAG_2);
> fn(a->strptr, b->length, 0);
Of course you do these with comments or #if's.
And when you are reasonably sure you have the code as it should be, you
tidy the code by deleting the unnecessary bits - safe in the knowledge
that you can always get it back when you need it.
Different developers will have different levels for when they use
"comment out" and when they use "delete and check-in". For people whose
idea of source code control is "make a new directory and copy everything
over" or "zip up the files as version 1.23.zip and copy to a usb flash
stick for backup" will make much more use of the "comment-out" style.
Developers who are strong git fans, use the command line interface
regularly (since it is much faster to use for common commands, once you
have learned it), and are happy with branching and merging - they will
be much more prone to making lots of small changes and checkins without
keeping old code in comments. And developers who use subversion and a
central repository will probably lie somewhere in the middle.
>
> In my editor, that's 4 key-presses (not including making the edit),
> although I'm always thinking of making that one key-press as it's such a
> common pattern. (Currently it's Alt-D, Up, Alt-1, then Down to get onto
> the new line.)
>
> Then, it's just two key-presses to swap the comments between the lines
> (Alt-0 then Alt-1 once positioned on the first). I don't want either
> line to disappear from view, even temporarily!
>
> I would really like to know how a separate command line utility is going
> to be help make such changes as effortlessly as above.
>
> I can't see #if 0 being much help either. How would it work on the first
> example:
>
> #if 0
> puts("ZPOPF1");
> #endif
> pc_udupl(a);
> #if 0
> puts("ZPOPF2");
> #endif
>
> Then I change the 0s to 1s? It's hard to figure out what's conditional
> and what isn't.
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-02 06:54 -0800 |
| Message-ID | <04880fa4-3dae-482c-8849-a9e70adb5f69@googlegroups.com> |
| In reply to | #77619 |
On Wednesday, December 2, 2015 at 8:24:48 AM UTC-6, David Brown wrote: > Using a version control system, you /replace/ the old version with the > new one, and check it in with an appropriate comment. If you ever need > to refer to the old version, it's still there on the version control > server and can be recovered and view as needed. What are your thoughts about: #undef USE_OLD_WOOZLER #ifdef USE_OLD_WOOZLER ... variable declarations used by old woozler code #endif #ifdef USE_OLD_WOOZLER ... old code #else ... new code #endif in cases where one may not be expecting to ever use the old woozler code again, but where it might be necessary to use the old code if e.g. problems arise when trying to use the new code and one wants to see if it's the new code that's causing the problem. Using "if ()" rather than #ifdef is often desirable, but won't suffice if the old code needs static or external variables that the new one does not, especially if the old code would have dependencies which would be acceptable in a development environment but not in a production environment. While #ifdef is nasty in some important ways (e.g. refactoring tools will often be blind to code which is #ifdef'ed out), I'm not sure how else to disable dependencies that would be unacceptable in production builds.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-02 16:40 +0100 |
| Message-ID | <n3n38a$rho$1@dont-email.me> |
| In reply to | #77620 |
On 02/12/15 15:54, supercat@casperkitty.com wrote: > On Wednesday, December 2, 2015 at 8:24:48 AM UTC-6, David Brown wrote: >> Using a version control system, you /replace/ the old version with the >> new one, and check it in with an appropriate comment. If you ever need >> to refer to the old version, it's still there on the version control >> server and can be recovered and view as needed. > > What are your thoughts about: > > #undef USE_OLD_WOOZLER > > > #ifdef USE_OLD_WOOZLER > ... variable declarations used by old woozler code > #endif > > #ifdef USE_OLD_WOOZLER > ... old code > #else > ... new code > #endif > > in cases where one may not be expecting to ever use the old woozler code > again, but where it might be necessary to use the old code if e.g. > problems arise when trying to use the new code and one wants to see if > it's the new code that's causing the problem. Using "if ()" rather than > #ifdef is often desirable, but won't suffice if the old code needs > static or external variables that the new one does not, especially if > the old code would have dependencies which would be acceptable in a > development environment but not in a production environment. > > While #ifdef is nasty in some important ways (e.g. refactoring tools will > often be blind to code which is #ifdef'ed out), I'm not sure how else to > disable dependencies that would be unacceptable in production builds. > It is similar to other cases - if you think it is unlikely that you will need the code again, it is neater to delete it and use your revision control system to recover the old code if necessary. Replacing the old code with new code also makes it easier to use differencing tools to see exactly what has changed. But if the balance is that you prefer to keep the code around, then using a specific symbol like this helps make it clear exactly what you are doing, and makes it easier to change between the old and new code - it is a good step up from comments or "#if 0". I have a preference to using #define USE_OLD_WOOZLER 1 // The old stuff is slow but tested //#define USE_OLD_WOOZLER 0 // New but possibly fragile code #if USE_OLD_WOOZLER == 1 ... #endif // USE_OLD_WOOZLER == 1 #if USE_OLD_WOOZLER == 0 ... #endif // USE_OLD_WOOZLER == 0 or #if USE_OLD_WOOZLER ... #else // !USE_OLD_WOOZLER ... #endif // USE_OLD_WOOZLER I prefer the symbols to be defined with a value that is checked - it makes it easier to navigate the code.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-02 18:24 +0000 |
| Message-ID | <slrnn5udqn.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77613 |
On Wed, 2015-12-02, David Brown wrote: > On 02/12/15 12:52, BartC wrote: ... >> Thanks, but I prefer using my own tools as I've always have done. ... > If you want to use git on Windows, get TortoiseGit: ... > However, for someone new to version control systems, especially a > Windows user, I would not recommend git. I would suggest subversion > (with TortoiseSvn for windows). Git is significantly more powerful - > but also significantly more complex. Compared to having a bunch of > files in a directory, subversion gives you an extra dimension - it lets > you track changes over time. Git gives you two extra dimensions - time, > and also branches. So with a view to learning to walk before you try to > run, and because walking is often perfectly sufficient and a big > improvement over standing still, I suggest you learn about subversion. > And since subversion has always been a cross-platform solution from its > conception, it does not feel as alien on Windows. I don't think we can convince BartC to do anything he hasn't done in the past decades ... But in general: I think that unless you /know/ you'll be forced to use Subversion at some point, it's better to skip that step and go directly to Git. Because it's not really a /step/ -- svn and Git require that you think in different ways. And Git is a lot more polished: better documented, better practical features for everyday use. IMO, one first way to use Git could be to - Ignore remotes; just do a 'git init' and do local version control like with Walter F. Tichy's 1980s creation, rcs(1). - Ignore branches; stick to master. - Focus on creating a sequence of well-defined and correct commits, and learn how to compare them. Learn how to use 'git rebase -i' and 'commit --amend' to make this happen. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-02 20:27 -0800 |
| Message-ID | <e3afc58d-c749-4605-a6ae-0b8529301569@googlegroups.com> |
| In reply to | #77646 |
On Wednesday, 2 December 2015 20:24:41 UTC+2, Jorgen Grahn wrote:
> On Wed, 2015-12-02, David Brown wrote:
> > On 02/12/15 12:52, BartC wrote:
> ...
> >> Thanks, but I prefer using my own tools as I've always have done.
> ...
> > If you want to use git on Windows, get TortoiseGit:
> ...
> > However, for someone new to version control systems, especially a
> > Windows user, I would not recommend git. I would suggest subversion
> > (with TortoiseSvn for windows). Git is significantly more powerful -
> > but also significantly more complex. Compared to having a bunch of
> > files in a directory, subversion gives you an extra dimension - it lets
> > you track changes over time. Git gives you two extra dimensions - time,
> > and also branches. So with a view to learning to walk before you try to
> > run, and because walking is often perfectly sufficient and a big
> > improvement over standing still, I suggest you learn about subversion.
> > And since subversion has always been a cross-platform solution from its
> > conception, it does not feel as alien on Windows.
>
> I don't think we can convince BartC to do anything he hasn't done in
> the past decades ... But in general:
>
> I think that unless you /know/ you'll be forced to use Subversion at
> some point, it's better to skip that step and go directly to Git.
> Because it's not really a /step/ -- svn and Git require that you think
> in different ways. And Git is a lot more polished: better documented,
> better practical features for everyday use.
>
> IMO, one first way to use Git could be to
> - Ignore remotes; just do a 'git init' and do local version control
> like with Walter F. Tichy's 1980s creation, rcs(1).
> - Ignore branches; stick to master.
> - Focus on creating a sequence of well-defined and correct commits,
> and learn how to compare them. Learn how to use 'git rebase -i'
> and 'commit --amend' to make this happen.
It seems that hg ("mercurial") works faster, has better tool support and
has more intuitive command line than git. IOW it is more novice friendly.
Especially it seems to save time with bigger team where some yet not
familiar with neither repo. If all are already familiar with one or other
then there are no problems.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-02 23:22 -0800 |
| Message-ID | <lnio4gq9ni.fsf@kst-u.example.com> |
| In reply to | #77702 |
Öö Tiib <ootiib@hot.ee> writes:
[...]
> It seems that hg ("mercurial") works faster, has better tool support and
> has more intuitive command line than git. IOW it is more novice friendly.
> Especially it seems to save time with bigger team where some yet not
> familiar with neither repo. If all are already familiar with one or other
> then there are no problems.
Perhaps. On the other hand, git is more popular, so experience with git
could be more valuable in the long run that experience with Mercurial.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-03 00:57 -0800 |
| Message-ID | <09859430-3bdc-4e3f-9a3a-a3eace824691@googlegroups.com> |
| In reply to | #77710 |
On Thursday, 3 December 2015 09:22:25 UTC+2, Keith Thompson wrote:
> Öö Tiib <ootiib@hot.ee> writes:
> [...]
> > It seems that hg ("mercurial") works faster, has better tool support and
> > has more intuitive command line than git. IOW it is more novice friendly.
> > Especially it seems to save time with bigger team where some yet not
> > familiar with neither repo. If all are already familiar with one or other
> > then there are no problems.
>
> Perhaps. On the other hand, git is more popular, so experience with git
> could be more valuable in the long run that experience with Mercurial.
Yes, git is perhaps whole order of magnitude more popular. Maybe Mercurial
is overly intuitive so that feeling of accomplishment and gaining valuable
experiences is missing. :)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-03 23:44 +0000 |
| Message-ID | <slrnn61kvo.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77712 |
On Thu, 2015-12-03, Öö Tiib wrote:
> On Thursday, 3 December 2015 09:22:25 UTC+2, Keith Thompson wrote:
>> Öö Tiib <ootiib@hot.ee> writes:
>> [...]
>> > It seems that hg ("mercurial") works faster, has better tool support
Is that on Windows, or over NFS, or something? I haven't tried hg,
but I fail to see how something could be faster.
Or have better tool support, for that matter. Although I only use the
shell, so I don't quite see what this means -- IDE integration?
>> > and
>> > has more intuitive command line than git. IOW it is more novice friendly.
>> > Especially it seems to save time with bigger team where some yet not
>> > familiar with neither repo. If all are already familiar with one or other
>> > then there are no problems.
>>
>> Perhaps. On the other hand, git is more popular, so experience with git
>> could be more valuable in the long run that experience with Mercurial.
>
> Yes, git is perhaps whole order of magnitude more popular. Maybe Mercurial
> is overly intuitive so that feeling of accomplishment and gaining valuable
> experiences is missing. :)
Let me assure you, that's not the reason /I/ enjoy Git. I learned it
a few years ago, and wouldn't have minded /at all/ if it has been
easier to learn! Or to teach to others! Most people hate learning
new things.
On the other hand, there are no features I would be willing to
sacrifice in order to make Git more newbie-friendly.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-03 21:17 -0800 |
| Message-ID | <3860201e-8271-4a20-bacc-5d17dfb34fca@googlegroups.com> |
| In reply to | #77785 |
On Friday, 4 December 2015 01:45:06 UTC+2, Jorgen Grahn wrote:
> On Thu, 2015-12-03, Öö Tiib wrote:
> > On Thursday, 3 December 2015 09:22:25 UTC+2, Keith Thompson wrote:
> >> 嘱 Tiib <ootiib@hot.ee> writes:
> >> [...]
> >> > It seems that hg ("mercurial") works faster, has better tool support
>
> Is that on Windows, or over NFS, or something? I haven't tried hg,
> but I fail to see how something could be faster.
I have used OS-X lately as development platform. Odd feeling that I don't
know what is going on is reduced there. Yes, synchronizing local repo
over network services feel faster, neither repo takes perceivable time
locally.
> Or have better tool support, for that matter. Although I only use the
> shell, so I don't quite see what this means -- IDE integration?
Somewhat more intuitive command line makes it perhaps easier to integrate
as well. People in my teams use editors what they want ... but repo has to
be same, constantly round-tripping between several repos is too much.
>
> >> > and
> >> > has more intuitive command line than git. IOW it is more novice friendly.
> >> > Especially it seems to save time with bigger team where some yet not
> >> > familiar with neither repo. If all are already familiar with one or other
> >> > then there are no problems.
> >>
> >> Perhaps. On the other hand, git is more popular, so experience with git
> >> could be more valuable in the long run that experience with Mercurial.
> >
> > Yes, git is perhaps whole order of magnitude more popular. Maybe Mercurial
> > is overly intuitive so that feeling of accomplishment and gaining valuable
> > experiences is missing. :)
>
> Let me assure you, that's not the reason /I/ enjoy Git. I learned it
> a few years ago, and wouldn't have minded /at all/ if it has been
> easier to learn! Or to teach to others! Most people hate learning
> new things.
>
> On the other hand, there are no features I would be willing to
> sacrifice in order to make Git more newbie-friendly.
hg feels to have more restrictions to workflow but these restrictions
seem to be helpful with bigger teams.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-05 00:43 +0000 |
| Message-ID | <slrnn64cp0.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77798 |
On Fri, 2015-12-04, Öö Tiib wrote: > On Friday, 4 December 2015 01:45:06 UTC+2, Jorgen Grahn wrote: ... >> On the other hand, there are no features I would be willing to >> sacrifice in order to make Git more newbie-friendly. > > hg feels to have more restrictions to workflow but these restrictions > seem to be helpful with bigger teams. Git is a bit like ClearCase that way -- anything is possible, and it's up to you to turn it into the right kind of version control for /your/ project. Last time I used Git in a project we used "Gerrit" for managing a central repository. I liked parts of it and disliked other parts, but it added plenty of restrictions to what you could do to the central repository. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-12-04 20:32 -0600 |
| Message-ID | <n3thtv$uks$1@dont-email.me> |
| In reply to | #77863 |
Jorgen Grahn wrote: > On Fri, 2015-12-04, Öö Tiib wrote: >> On Friday, 4 December 2015 01:45:06 UTC+2, Jorgen Grahn wrote: > ... >>> On the other hand, there are no features I would be willing to >>> sacrifice in order to make Git more newbie-friendly. >> >> hg feels to have more restrictions to workflow but these restrictions >> seem to be helpful with bigger teams. > > Git is a bit like ClearCase that way -- anything is possible, and it's > up to you to turn it into the right kind of version control for /your/ > project. > ClearCase... well, the less said the better. The last time I used it, you had to *lock individual files*. And you could not save changes until you did. https://xkcd.com/1597/ > Last time I used Git in a project we used "Gerrit" for managing a > central repository. I liked parts of it and disliked other parts, but > it added plenty of restrictions to what you could do to the central > repository. > > /Jorgen > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-05 16:06 +0000 |
| Message-ID | <slrnn662rd.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77872 |
On Sat, 2015-12-05, Les Cargill wrote: > Jorgen Grahn wrote: ... >> Git is a bit like ClearCase that way -- anything is possible, and it's >> up to you to turn it into the right kind of version control for /your/ >> project. > > ClearCase... well, the less said the better. The last time I used it, > you had to *lock individual files*. And you could not save changes until > you did. Lots of people dislike ClearCase. File locking (like in old RCS, remember?) wasn't that much of a problem in practice, IMO. The worst part was: - Very poor diffing support. - "Config specs" which decide which branch you look at/work on tended to become spaghetti code, and a bug there could ruin your work. - Almost noone uses it these days. > https://xkcd.com/1597/ Thanks! That's more true than I'd like to pretend it is. I'll use it in the intro text to version control which I'm writing for my cousin ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-12-05 13:10 -0600 |
| Message-ID | <n3vcch$9g9$1@dont-email.me> |
| In reply to | #77894 |
Jorgen Grahn wrote: > On Sat, 2015-12-05, Les Cargill wrote: >> Jorgen Grahn wrote: > ... >>> Git is a bit like ClearCase that way -- anything is possible, and it's >>> up to you to turn it into the right kind of version control for /your/ >>> project. >> >> ClearCase... well, the less said the better. The last time I used it, >> you had to *lock individual files*. And you could not save changes until >> you did. > > Lots of people dislike ClearCase. File locking (like in old RCS, remember?) > wasn't that much of a problem in practice, IMO. but this is a mass disimprovement over even (slightly less) old CVS. > The worst part was: > - Very poor diffing support. Very. > - "Config specs" which decide which branch you look at/work on > tended to become spaghetti code, and a bug there could ruin > your work. Just awful. You needed a version control system outside ClearCase to control them. > - Almost noone uses it these days. > Thank $DEITY. It's certainly doable but it wastes time and human bandwidth unnecessarily. >> https://xkcd.com/1597/ > > Thanks! That's more true than I'd like to pretend it is. I'll use it > in the intro text to version control which I'm writing for my cousin > ... +1 > > /Jorgen > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-06 10:18 +0000 |
| Message-ID | <slrnn682r4.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77908 |
On Sat, 2015-12-05, Les Cargill wrote: > Jorgen Grahn wrote: [ClearCase] >> - "Config specs" which decide which branch you look at/work on >> tended to become spaghetti code, and a bug there could ruin >> your work. > > Just awful. You needed a version control system outside ClearCase > to control them. Yes. I wrote one myself ;-) and used three or four others of varying quality. Every project rolled their own. Config specs were a neat idea, which kept policy away from the core ClearCase functionality ... but they also dumped the policy decisions in the laps of people who couldn't usually handle them. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web