I've honestly never understood the perspective of eliminating merge commits (though I've had to work with it, and the rebasing required got me into some of the worst git snafu's I've ever been in). Merges are history too. Why would anyone want to loose the information that code was merged from a branch? For example if the problem was introduced when code lines were merged, that's useful info about when/how it happened and where more attention needs to be focused.
Not saying it's wrong, just saying I don't understand it... I like git and use it where I can, but as was noted earlier it will probably be necessary for the project to establish the way they wish to use or it will likely create significant chaos as one person tries to eliminate merges in the history and another person preserves them; One person forks and makes pull requests while another commits directly... who reviews the pull request... Do commiters use pull requests, or only non-commiters? Food for thought: https://www.atlassian.com/git/tutorials/comparing-workflows/ I don't use the github repo for solr when I build it from the repo right now because it seems to be a secondary "add on" and I always favor the canonical source, because the last thing I want is to deal with an extra layer and figuring out where the pitfalls in the translation between layers might be. My $0.02, Gus On Mon, Jun 1, 2015 at 2:37 AM, Ramkumar R. Aiyengar < [email protected]> wrote: > > There is only one good rule though - no merge commmits in the history :) > Ever. Do whatever you want beyond that. A clean, simple history for each > branch is the only sensible use of Git I've seen. > > +1 > > > > > - Mark > > > > > > On Sat, May 30, 2015 at 9:00 AM Adrien Grand <[email protected]> wrote: > >> > >> The main benefit I see is that external contributors would get their > >> name in the commit log. > >> > >> However on the other hand, I'm a bit annoyed that people easily > >> disagree on the workflow: some people merge into the maintenance > >> branch first and then to master, other people merge into master first > >> and then cherry-pick, other people prefer rebasing instead of merging, > >> etc. I personally don't really care but if we agree on moving to Git, > >> I hope we can agree on the workflow at the same time. At least today > >> with svn we have something simple that everybody agrees on. > >> > >> -0: I'm not against it but Subversion works well for me today. If > >> everybody else agrees on switching to Git I would like us to agree on > >> the workflow as well. > >> > >> -- > >> Adrien > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > -- > > - Mark > > about.me/markrmiller > -- http://www.the111shift.com
