On 5/16/07, Andy Parkins <andyparkins@xxxxxxxxx> wrote:
I quite like option 2 because it records intent - i.e. "I wish I could have gone back and changed this revision, but I can't", but it makes a more complicated history.
I prefer just letting history show what happened, rather than try to get too smart about it ;-) -- and use branches and merges for experimental or feature work. Once a feature or experimental branch is merged into master, further work happens on master (unless there are other reasons for it to be maintained). Bugfixes are part of the life of the maint and master branches. Imagine your "option 2" being used to maintain git's maint branch. Some bugs live in the code for 6 months. The merge graph would be unreadable... and generally the project history would be really hard to make sense of. Most "special" practices around branches kind-of work in the minimalistic case, but break down badly in real-life sized projects... cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
