If you do that when manually merging that's ok. Give references to the PR, not just push multiple-commits without any track if they were bundled or not, that was my main point. If you don't understand what's happening, there's git log --no-merges.
On Tue, Sep 2, 2014 at 8:23 PM, Rok Garbas <r...@garbas.si> wrote: > 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 > -- www.debian.org - The Universal Operating System
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev