On Tue, Mar 26, 2013 at 01:29:53PM +0100, Romain Francoise wrote: > Nicholas Marriott <nicholas.marri...@gmail.com> writes: > > > If we have nice history it is a bonus but if it's easier then it'll be > > messed up. Why is this a problem? Every change is there at least once, > > nothing is lost. What can you no longer do here? > > It's fundamentally broken to have every change in there twice, one of > which has been discarded by the merge because it was already there. If you > checkout any of the intermediate revisions which originated from OpenBSD > then tmux doesn't build, because that code doesn't use the osdep_* > functions. So you can't bisect. This code shouldn't be there in the first > place, only the actual changes that were *only* in OpenBSD should appear > in the repository.
It is not important if some random revision picked out of the history builds or doesn't build, works or doesn't work. There are definitely no promises there! > > I know that the merge is correct, i.e. that after the merge (and fixups) > the master branch has the latest version of the portable code and 'git > log' of each file has only one version. But in six months when I get a bug > report about tmux 1.8 and want to see why a given change was made, I'll > have to look through history and it won't help to have every commit appear > twice... I think this is a stretch - looking for something in the history is a manual process and filtering out the odd duplicate is hardly that much extra work. The state of the history is perhaps aesthetically unpleasing but in practice I don't see how it is important. > > It should be easy enough to use a similar approach to what was previously > used, i.e. generate changesets from the OpenBSD CVS history and apply only > the ones that aren't in Git. I leave that up to Thomas, whatever is easiest for him. But so long as nothing significant is lost and we don't move the entire repository too often the method is not important to me. However, this was a special case because the changes were applied to Git and then ported to OpenBSD rather than the usual other way round. I'm not going to say we won't be doing that again though :-). > > > You can probably rely on the 1.6, 1.7 tags staying stable as well, but > > they are a convenience - it's better to use the tarballs. > > This is what I was doing when the repo used Subversion, I imported > tarballs into a Git repository. When we switched to Git I changed the > Debian packaging to be based on the new Git repo because it's much more > convenient, but if there is no guarantee that the master branch won't be > rewound at random times maybe I'll switch back to tarballs. We do release tarballs so that people have a stable point to build packages. I don't understand what master has to do with it, are you building packages from master rather than from a tag? I do like people to test Git but with the usual caveat that it is a development repository and may move or change or break in unexpected ways depending what is convenient for development. I wouldn't encourage you to build packages from it. ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
