As per Paul's request I started a new message thread...
[sorry Paul for all the previous OT messages]
Florian Klaempfl wroteThat's exactly my point: if somebody forgets it, things are screwed up and with every clone you've to play this game again.
Not really. core.autocrlf is automatically set to true for Windows versions of Git (msysGit I know is) - the msysGit installation actually gives you a choice, but the default is autocrlf = true under Windows.
Also, another simple way to prevent this whole EOL style issue, is to actually clone the repository from the flashdrive drive, instead of using it directly. Consider the repository on the flash drive as the "master" repository. Clone it to your Windows partition using Windows version of Git and do the same for Linux. By default each cloned repository on each platform will have the platforms native EOL style. Then pull/pull to that "master" repository on the flashdrive from both Linux and Windows. Then you don't have to ever worry about conflicting EOL styles. The repository on the flash drive can even (preferred) be a "bare" repository, meaning it only contains the git repository information (no branches are ever checked out on the flashdrive).
Now lets continue using the above example and say that the Windows platform is at home and the Linux platform your flash drive contains the "bare" master repository if you want to take work home. At work you can add a second upstream repository which is the company server. So while at work on your Linux system, you pull the changes from the flashdrive repository (things you worked on last night at home), and then push those changes back onto the company server repository.
Like I said, Git is a DSCM, so you need a slightly different thinking compared to a client/server SCM like SubVersion. Hence the reason I would suggest one re-evaluate ones workflow after adopting a DSCM, to make sure it is still the most optimized workflow for your toolchain.
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
Again a good reason to re-evaluate the workflow. I don't know how the Linux Kernel project works, but the git.git project has a very nice workflow. At fist it sounds confusing because it's quite different to how things are normally done in say a SubVersion repository, but after reading there workflow documentation once or twice you might notice how clever there workflow is and how well it works.
For documentation on how the git.git project workflow works and what the various "official" branches mean, see the following URL.
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
git.git repository allows features to "graduate" from experimental to release. All the while using feature branches which allows your to easily thow-away that features or let it graduate upwards to a more stable or release or maint branch.
Coming back to me "cherry-picking" for the fixes branches in Lazarus and SVN Git mirror repositories. I use cherry-picking simply because both Lazarus and SVN have linear development models which prevents me from using many smaller "feature" branches and thus "merging". My only remaining option was to use "cherry-picking" for FPC and Lazarus repositories.
At our office we have adopted a similar strategy to the git.git repository. This allows us to much easier keep track of "maintenance" and new experimental feature branches. And we have a MUCH smaller development team and repository that Git itself - yet the workflow still applies well.
How does this decrease the runtime of 5-30min (depending of the platform) of the regression test suite?
Not with the running time of the regression test suite, but in finding regression bugs. With 'git bisect' you save a huge amount of time! I have tried this on various regression bugs in Lazarus too, and it works very well. In most cases I can create a small self-test application and completely automate the finding of a regression bug.
Regards,
- Graeme -