[Nix-dev] About merge vs non-merge

[Rok Garbas]

Quoting Luca Bruno (2014-09-02 18:51:39)
> Somebody does not like merges because it makes the history "less clean".
> However, just today, I encountered a case where the merge was needed for
> a revert.
> 
> The good thing about the green merge button is that:
> 1) It retains a message about the PR. So you have information if you
> need to do a revert.
> 2) If it's a multi-commit PR, you may need to revert multiple commits.
> Without merge this information is lost.
> 
> For manual merges, yes it's very inconvenient. In theory one should either:
> 1) Edit every commit message saying that it was part of a given PR
> 2) or create a local branch mirroring the requester branch
> In both cases it's annoying.
> 
> However for anti-merge people, it may make the history less clean for
> you, but the lose of information is not worth it in my opinion. So I
> please everyone, if you can choose to have a merge commit, please keep it.
> 

all of the above points are non an issue when manually merging, becuase:
 - you squash all commits into one
 - you also add some more descriptive message if the one provided wasnt clear
 - you resolve conflicts with master since some PR can get outdates quite fast
   and asking 10 times the contributor to rebase on top of master is waste of
   time.
 - you check changes localy before you actually merge them anyway, so there is
   no reason also for not keeping history clean.

so all "merge loving ppl" please keep history clean. github merges are _bad_
practise said by not only me, i guess you can search google for this so i wont
spoil you the fun reading on this topic.

merges should be used with long living branches or bigger arhitecural changes
not with _every_ pull request. becuase looking at current nixpkgs history it
doesnt make much sense what is happening.


--
Rok Garbas - http://www.garbas.si