Re: [tei-council] Merging

True, but I think I'd argue we shouldn't be doing most of the debugging in master, but rather in the branch before it's ready to be merged. And in any case, if there is a problem, it should manifest before we've deleted the branch, and the branch will retain the full commit history. Plus, of course, knowing what commit it was doesn't necessarily help you fix it anyway :-) On Tue, Sep 29, 2015 at 11:19 AM, Martin Holmes wrote:

My instinct is to preserve everything, to be honest. But that comes from an SVN background; people using git tend to commit more frequently, in my experience.

It's much harder to debug a problem in a large squashed merge. If there's a series of staged commits, you can go back through them and find out which one introduced the problem.

Cheers, Martin

On 15-09-29 06:59 AM, Raffaele Viglianti wrote:

...

I'm not used to squashing my commits, but I can see how it would make for a much readable history for TEI, where we commit fairly often.

Raff

On Tue, Sep 29, 2015 at 3:10 AM, Peter Stadler wrote:

-----BEGIN PGP SIGNED MESSAGE-----

...

Hash: SHA1

Hmm, I don't think I'm interested in the development history of a feature. But of course, once it's in the master branch its history has to be preserved.

Just my 2 cents Peter

Am 28.09.2015 um 23:15 schrieb Hugh Cayless:

...

Realized we should probably discuss this a bit: when I merged the appcrit stuff, I did this:

git checkout hcayless-appcrit git merge master # this resulted in a conflict, which I fixed, then ran a commit to complete the merge git checkout master git merge --squash hcayless-appcrit # this sets up a merge by pulling all the changes over from the branch and setting up a commit for them # this means that instead of getting all the commits from your branch, you just get one with the results. git commit -m "Merged Critical Apparatus changes into master." git push origin master

I don’t really think it’s necessary to import my commit history from the branch, because it’s a) not very interesting and b) it’s still available until we’re done with the branch and delete it. But there’s room for disagreement. This method avoids hairy merges (you might have conflicts at any step and have to go through several rounds of conflict resolution) and results in a cleaner history, but it does mean we then don’t have the full record of how a feature was developed (except in the branch, which eventually will be deleted)…it’s a tossup. What do you all think?

-----BEGIN PGP SIGNATURE-----

iQEbBAEBAgAGBQJWCjlLAAoJEJclm6G69Xq26KgH90APake9jlOyl+ccFZz19jyZ mp13fSkBb7i8uU2WQNxCkIUkZ/QZpJL/nq2Rxz+6H5uyRBhVeI7SwyQquwb6RSjb TqyhX7lVTT3S56G1k0V1YFdwbUmsB9E7oKru/TGjNEUFPUqDVxkTCq0ZiGjRE7Np 7y/IEMZ4zkOYewkoCwVMvYpKZ3xTx9655bgiHPkoLK5cB2jJtYf1pnwJxZ1/H3j4 b3rSXvZlKKY82FutGZmrP6d/nxJl5CWxn9IX3WfaHTDnl0f7FX+/j6flSK2PzFfo 9NQnLEG1HII9sJHK4m/nmCMnN1a/81+at4ktndXSpCq99dFAXXI/8G4wuGEY7w== =STZh -----END PGP SIGNATURE----- -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived