search

friendly / VCDR

Visualizing categorical data with R
0 stars 0 forks source link

revision2 branch #40

Closed philchalmers closed 9 years ago

philchalmers commented 9 years ago

There seems to be a fork in the workflow which might cause some confusion. There are now two working branches, revision1 and revision2, both of which have different history (so a merge or rebase is required). Which one should be considered the 'master' version?

As an aside, if a branch was only created to make a snapshot of the last release, consider using a tag instead:

git tag -a v2.0 -m 'Second version sent to publisher'
git push --tags
davidjohannesmeyer commented 9 years ago

The idea was to put all edits after the submission in a separate branch, based on revision1 - is this not the current state, or the way to go? We wanted to keep separate the edits from the publisher and ours, and later merge both into revision1, which currently plays the role as our master. Is this a bad idea?

Thanks David

On 2015-06-14 16:42, Phil Chalmers wrote:

There seems to be a fork in the workflow which might cause some confusion. There are now two working branches, |revision1| and |revision2|, both of which have different history (so a merge or rebase is required). Which one should be considered the 'master' version?

As an aside, if a branch was only created to make a snapshot of the last release, consider using a tag instead:

git tag -a v2.0 -m 'Second version sent to publisher' git push --tags

— Reply to this email directly or view it on GitHub https://github.com/friendly/VCDR/issues/40.

FH-Prof. Priv.-Doz. Dr. David Meyer Institut für Wirtschaftsinformatik

Fachhochschule Technikum Wien Höchstädtplatz 5, 1200 Wien T: +43 1 333 40 77-394 F: +43 1 333 40 77-99 394 E: david.meyer@technikum-wien.at I: www.technikum-wien.at

philchalmers commented 9 years ago

Seems like a good plan to me, but if so then all edits on revision1 should stop in order to a) avoid future merge conflicts with revision2, and b) prevent physical conflicts with the copy editor. As well, the Github default branch be changed to revision2 so that automatic closing of issues will still work. @friendly would you mind switching the default branch again?

friendly commented 9 years ago

I'm in transit No access fora day or two

Sent from my iPhone

On Jun 14, 2015, at 5:26 PM, Phil Chalmers notifications@github.com wrote:

Seems like a good plan to me, but if so then all edits on revision1 should stop in order to a) avoid future merge conflicts with revision2, and b) prevent physical conflicts with the copy editor. As well, the Github default branch be changed to revision2 so that automatic closing of issues will still work. @friendly would you mind switching the default branch again?

— Reply to this email directly or view it on GitHub.

friendly commented 9 years ago

Back on the web. Was there any decision about whether to keep new work on revision2 (changing it to the default branch) vs. anything else?

philchalmers commented 9 years ago

I think it makes sense to change over to revision2 for now and freeze the revision1 branch. That being said, revision2 should be updated with the recent changes from revision1 via a git merge so that all the recent changes are still in one focal branch.

friendly commented 9 years ago

OK by me. Can you or David take care of this?
Then I'll switch my local repo to rev2

philchalmers commented 9 years ago

Done. Just switch over the Github default branch to revision2, then this issue is complete.

rbarnhart commented 9 years ago

Hey Phil,

I have a few questions for you later. Could I call you at some point.

Ryan

Sent from Surface

From: Phil Chalmers Sent: ‎Friday‎, ‎June‎ ‎19‎, ‎2015 ‎2‎:‎51‎ ‎PM To: friendly/VCDR

Done. Just switch over the Github default branch to revision2, then this issue is complete.

— Reply to this email directly or view it on GitHub.