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

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

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

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

You can do git tag -l archived* for a list of tags that have the archived/ prefix. prefixing archived branches with "archived/" is a convention, but seems like a decent idea. There are various ways to search through the entire commit history and ways you could do so starting from each tag starting with archived/, so the answer is yes, but you’d have to do a bit of scripting. The other answer is that if they’ve been properly synced up with master, then you’re not going to learn anything you wouldn’t find using git log and its various options on the master branch, where you can fairly easily ask that question. You probably already know what branch belongs to whom from the names.

On Sep 29, 2015, at 14:46 , Syd Bauman wrote:

I think this may be exactly what I was hoping for when I asked about hiding or moving the branch instead. But we may not remember it was hcayless-appcrit as opposed to hughc-critapp. How does one get a list of branches that have been tagged and deleted? Something like 'git list archived/'?

And can you ask the question "which archived branches had commits from MrClean more than a month ago?"?

...

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

I think it's fair to say that exceptions might arise. Branches can stick around as long as we want them. They'll start to clutter the place up eventually if we don't delete any of them, but there's no deadline for getting rid of them. Something really big, like P6, for example, will probably start as a branch, but we might decide to keep it around, do a full merge into master, or maybe even just make it into master and master into "P5". On Tue, Sep 29, 2015 at 11:52 AM, Syd Bauman wrote:

I'd be lying if I said I understood this, but my instinct is that it's not completely predictable when we might want to keep the revision history for a develop-a-feature branch and when we wouldn't. I suspect that, for the most part, the commit hx for such a branch is not sufficiently useful that we should keep it around. But I can imagine the opposite for a particular feature.

If we fold only the tip of a branch into master, we lose the commit hx when we delete that branch, right? Is there any particular advantage to deleting the branch? Can it be merely hidden or moved instead? -- 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