Hi, > I've noticed recently that our git repo is a bit weird looking. > I'm talking about commit sequences > a291087ad5ef010074ad2d4b1679fcc2cdf667c5..0f49b04dc9c6062a2fd6f480449270123ff7f6b7 > and > 742472c23d67b6d62730c329d09e1bdac63bd22b..0bfcd3c4029fcf886e3ab5001a7dc75860457095. > > What's wrong with them? As for code changes they are OK. The way they've > been forked / merged / re-merged and finally pushed made git repo pretty > messy. > As human brain is mostly used to think in linear timeline it's easy e.g. > to look for bugs in linear sequence of code changes but you will very > quickly get lost in the number of parallel branches. > > That's why our golden rule is - don't merge, rebase - it's an easy way > to keep git repo as much linear as possible.
First of all, I am sorry for the confusion. The reason for such a strange-looking history depends on the fact that multiple developers from the Spacewalk community and multiple developers at SUSE are concurrently committing a big number of fixes to the user interface due to the recent Twitter Bootstrap changes. Since those changes are many (currently tens of commits a week), we agreed on having a single branch for all fixes from SUSE employees (master-bootstrap-css-fixes). This allows me to push it frequently to the Spacewalk repo instead of sending individual patches via email, thereby greatly simplifying code submission. Naturally, commits from this branch are to be applied to master (either by merging or rebasing/cherry-picking) by others in the Spacewalk community in order to ensure proper reviewing. We also need to keep this branch updated since master changes quite frequently. Among other things, this ensures our fixes can be applied cleanly after being reviewed without extra work. Of course we can do that by rebasing, but it will require force pushing/history rewriting, which is not very convenient since we have multiple developers and designers working on that (currently 6 people). So we prefer merging master into master-bootstrap-css-fixes from time to time, because this does not require force pushing, that is talking to/stopping 6 people every time master changes significantly (and it does, see for example 559ab061). I asked Tomáš Kašpárek if this was acceptable: <moio> tkasparek: since various people work on master-bootstrap-css-fixes here, we do not really like force pushing. At the moment we are merging master back to the branch from time to time - I hope that you don't mind some extra merge commits <tkasparek> moio: sure, just do whatever suits you the best <moio> tkasparek thanks <tkasparek> np I hope this is not really a difficult issue, as I am happy with the current upstream patch flow that, being quite fast, allows lots of bugs to be solved efficiently. Final note for a future discussion: we would also be very happy if you had an official GitHub account and could accept pull requests, as we already do internally. That would also address this problem cleanly in my opinion! Regards, -- Silvio Moioli SUSE LINUX Products GmbH Maxfeldstraße 5, 90409 Nürnberg Germany _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
