Graeme Geldenhuys schrieb: > Florian Klaempfl wrote: >> person working with the file will find out only. This is the simplest >> case, it gets more complicated if one works on samba shares and >> tortoisesvn with unix editided files like I do often :) > > I use my flashdrive like that. I simply told git to always store files as > LF in the repository. Any editor (worth using) can handle files with > different end-of-line characters compared to the default OS. > > If I really wanted to change my files to CRLF for usage under Windows, I > can simply run 'git config core.autocrlf true' and then 'git reset --hard'.
That's exactly my point: if somebody forgets it, things are screwed up and with every clone you've to play this game again. > > >> talking about the fix one, break one design of git. How shall we adapt >> the workflow so that nobody wastes it time with trying to merge stuff >> somebody else examined already? > > Simply pull that feature branch from the developer that already did the > merge. You realize that fixes is not a feature branch but cherry picking? So what are the means to prevent that people look again and again to merge a certain changeset even if somebody already decided that this changeset will not be merged? > > There are many other such use-cases where DSCM's like Git and Mercurial > will trump SubVersion every time. And like you said, you spend a lot of > time doing regression tests. (did I mention you can automate regression bug > tracking with Git using simple test projects like the ones used in FPC > tests directory) How does this decrease the runtime of 5-30min (depending of the platform) of the regression test suite? -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
