Re: [tei-council] Merging

What documentation? All the current Council work documentation is studiously silent about gittery. On 29/09/15 19:22, Martin Holmes wrote:

This sounds perfect to me. Shall we add it to the documentation?

Cheers, Martin

On 15-09-29 09:23 AM, Hugh Cayless wrote:

...

Looks like the best practice is to tag your branch and then delete it. That way it's not cluttering up your list of branches, but you can still get at it if you need to:

git tag -a archived/hcayless-appcrit # write a description of what's in the branch git push origin archived/hcayless-appcrit git branch -d hcayless-appcrit git push --delete hcayless-appcrit

That tags and annotates the branch, pushes it up to Github, deletes the branch locally, and then deletes in on the remote. If you want to go digging through the old branch, you can do

git checkout -b hcayless-appcrit archived/hcayless-appcrit

And you'll have a local copy you can mess around with. I like that. Thoughts?

On Tue, Sep 29, 2015 at 12:07 PM, Lou Burnard wrote:

...

True, but it's in the nature of things that some thing you didn't anticipate causing problems halfway through your local branch work will be the one thing that comes back to bite everybody six months later. So I'd say keep everything, if you're going to keep anything. Disk space is cheap. Tools for searching the backlog exist (I assume).

On 29/09/15 16:26, Hugh Cayless wrote:

...

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

-- 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