Ivan if you do the editing, please use a pull request for merging to master.
It is an advantage to use a pull request for several reasons.
This is the 'best practice' in git/GitHub.
Eliminating the 'merge commit' is not an advantage but a disadvantage.
Don't do it again, please.
- Josef
Merging algorithm
-
Ivan Denisov
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Issue #22: HostFiles.NewWriter violating the specificati
Why do you think, that it is better? Can you give some arguments, please?Josef Templ wrote:Ivan if you do the editing, please use a pull request for merging to master.
It is an advantage to use a pull request for several reasons.
This is the 'best practice' in git/GitHub.
Eliminating the 'merge commit' is not an advantage but a disadvantage.
Don't do it again, please.
-
Ivan Denisov
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Merging algorithm
Josef, each merge of branches or creation of branches with GitHub creates the extra duplicate of BlackBox in our VPS. While with creation of branch in PC you will not get extra copy. Making the merge in PC and GitHub is similar in the low level of git commands. However when you make it with GitHub you again get extra copy and trash in the maser branch history. If too look in this merge points as separators they are useless in case of simultaneous work in few branches as we do now, because each file have own history in general.
-
Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Merging algorithm
As far as I know, using pull request is THE standard in git/GitHub.
It is well supported by GitHub. It is very simple and convenient to do.
You can do it from the GitHub web interface, i.e. you don't need to have a local repository etc. etc. etc.
We did it until now and should not produce a mix of conventions from now on.
When I started to use git I also thought that eliminating the pull request would be an advantage.
It is not. Note that there is no physical copy of anything going on, i.e. the repository does not grow!
The practical advantage of having a merge-pull-request is:
If you look at the sequence of COMMITS in the master branch, the merge-pull-request clearly separates
the commits that belong to a particular issue. The merge-pull-request entry also accumulates all
the changes that belong to a particular issue no matter in how many little commits they were
split. So, if you want to see all the files that were affected by a particular issue, simply select the
merge-pull-request entry in the git log.
You can also set a filter and only look at the merge-pull-requests of master, for example.
This makes it very simple to see what changes have been done for which issue.
Eliminating the merge-pull-request would only be an advantage if all the changes that belong to an issue
are done in a single commit. Then there is no need for grouping the commits that belong to an issue.
This is not realistic in general, however.
- Josef
It is well supported by GitHub. It is very simple and convenient to do.
You can do it from the GitHub web interface, i.e. you don't need to have a local repository etc. etc. etc.
We did it until now and should not produce a mix of conventions from now on.
When I started to use git I also thought that eliminating the pull request would be an advantage.
It is not. Note that there is no physical copy of anything going on, i.e. the repository does not grow!
The practical advantage of having a merge-pull-request is:
If you look at the sequence of COMMITS in the master branch, the merge-pull-request clearly separates
the commits that belong to a particular issue. The merge-pull-request entry also accumulates all
the changes that belong to a particular issue no matter in how many little commits they were
split. So, if you want to see all the files that were affected by a particular issue, simply select the
merge-pull-request entry in the git log.
You can also set a filter and only look at the merge-pull-requests of master, for example.
This makes it very simple to see what changes have been done for which issue.
Eliminating the merge-pull-request would only be an advantage if all the changes that belong to an issue
are done in a single commit. Then there is no need for grouping the commits that belong to an issue.
This is not realistic in general, however.
- Josef
Last edited by Josef Templ on Tue Dec 23, 2014 4:58 pm, edited 1 time in total.
-
Ivan Denisov
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Merging algorithm
Thank you for the answer. I am also reread the wiki page:
http://wiki.blackboxframework.org/index ... p_with_Git
and agree with your strategy. I will make the pull requests.
So, the work on the issue, should be completed in the issue branch and pushed into the repository before merge in web-interface. Two extra copy can be deleted as the all other non master branches builds later.
http://wiki.blackboxframework.org/index ... p_with_Git
and agree with your strategy. I will make the pull requests.
So, the work on the issue, should be completed in the issue branch and pushed into the repository before merge in web-interface. Two extra copy can be deleted as the all other non master branches builds later.