New updated icons7

[ucapato]

Update at Scholastic Publisher and new and renamed icon. Fix on Year date order for Publishers: Dark Horse, DC Comics, DK Publisher, and Globo.

[maforget]

The idea that you update master before creating a new branches is so you can create a new branch that is up to date with the master. So any changes you do will be the most up to date. But you keep reusing the same branches and adding on top of them even if they have already been merged.

Once a branch has been merged, you can delete it on Github and also locally. And create a new one for each occasion. Don't forget that you can create branches locally as much as you want and then push them to Github when you are satisfied. If I look at your commit history for https://github.com/ucapato/ComicRackCE/commits/NewUpdatedIcons7/, I should have basically the same has mine, with others on top (for small merge like that anyway). Your have a bunch of your own commits, but none of those from mine. This is why you keep seeing a list of commits that have already been merged.

Github is intelligent enough to show only what was change in the Files Changed. But it can't merge them because it is missing some commits. Right now you are pushing changes to Dark Horse Comics, but there is a conflict somewhere. So the program is confused knowing that the file from master has changed. Requiring using the command line to fix it.

Someone else did post today another PR with the Scholastic image this morning. But yours looks better, so I will merge this one instead.

[maforget]

I've just cherry-picked it, it was easier.

[ucapato]

I see,

I am probably missing a step (or some steps) during my "merge, update, pull/push procedures". I insist in keeping using some git command lines, instead of only Git App itself as I need to use git (occasionally) at my work. So I take the practices here as also exercises to use at my job.

Usually, I follow this sequence of commands:

Keep my fork (local repo in my machine) up to date:

fech changes from upstream

git fetch upstream

check out my local master branch

git checkout master

merge changes from upstream/master into my local master

git merge upstream/master

push the updated master branch to my fork

git push origin master

Only after that, I created a new branch to make some updates:

create and checkout the new branch

git checkout -b NewUpdatedIcons8

I perform any changes/updates as needed, and then I commit them: git add. git commit -m "Describe the changes"

Then I push the branch to my Fork: git push origin NewUpdatedIcons8

Only then, I open the Git Hub App and create a Pull Request (CTRL+R).

But as I mentioned, it seems I am doing everything locally and not reflecting the same on the GitHub page itself. For the NewUpdateIcons7 branch, I saw I did the two last updates on it, and that should be in different branches. What I have just realized recently is that I had most of the previous branches still created on Git Hub, even after I've deleted them locally in my machine (Either by command line or through the Git Hub app).

I saw for every merged commit, there is a "Delete Branch". I will use it as soon as I see the commit is merged.

I had the wrong thought that using 'fetch upstream' and merging it to my local fork would update the scenario on guithub page. When I am in reality only updating the repo locally on my machine. For every creation/deletion of branches, I need to reflect that on the GitHub page as well. Probably this is the main mistake (as far as I understood).

Thanks for the patience to bring some comments to my activities it is helping a lot to make it better.

[maforget]

I am really not super used to all the command line. I find it easier to use the GUI of Visual Studio. ALso did you know that there is a gui with git directly. Just type gitkin a folder that contains the .git folder. At least it helps visualize things better.

What you can do when creating your branch is to use my master as the source: git checkout -b NewUpdatedIcons8 upstream/master

It will create a branch based on my master, so no need to mess with merging your master. There is also a button to sync the fork on your GitHub page that you can use. Than all you need to do is git pull.

But no things you change locally aren't changed on the remote. Even if you delete the branch on Github, but keep it locally it will just create a new one when you push it. Before pushing, check either the Github Desktop or gitk or IntelliJ to see what your branches looks like. You can freely change between program and the will pickup where the last one left. Like checkout my branch with the Github client but continue working with the command line after that.

In case your local branch doesn't match with the Github branch, usually you need to push with --force.

[ucapato]

Hi,

This is something interesting, that I am trying to understand. When I check my fork on the Github page I have this:

It says my branch is 8 commits ahead of yours. But when I try to sync:

It says the branch is not behind the upstream.

when I click on "8 commits ahead of", it leads me to:

So, does Git Hub count " Merge remote-tracking branch 'upstream/master' " as a commit?

Another thing is when I opened "gitk". It shows my Branch "NewUpdateIcons8" as already in July 05th, but I have just created this branch this week:

Maybe this is why it is shown to you as one commit at the top of another in the same branch?

[maforget]

The 8 commits ahead are the merge and commits that were done when your branch parent was older. Since those merge don't exist in my repo, it will always say that unless you rebase or reset. But it does say that you are up to date. It just means you are at the same point as the upstream HEAD. It is a correct way to work, but you might stumble upon a point were there is a merge that has conflicts that you will need to fix to complete the merge. Not always the easiest if you don't really know what was changed. That is why I advised to keep it clean so you would never have merge conflicts if all you do is pull from my master. When doing a normal pull from the same tree it create a fast forward merge (just recreating all the commits).

That branch appears there because that commit is part of that branch. If you've just create NewUpdatedIcons8 pretty much the whole tree would have that. If you would see any old builds that would be an indication that the old branch was not deleted locally.

What is also happening is that when I merge a PR, I have the option to merge or squash and merge. Squash and Merge will combine all the various commits to only 1 and show only that. It is especially useful when there are multiple commits for 1 PR. Like for example in PR #109 but at the end the master commit as only 1 entry 7a74d191bd9eafb55408c5891bf138509c65f16a. Or with yours when multiple commits appear it is squashed to only the important change and not show all the merge to just update unrelated changes.

Since the commit history is shown in News window, I don't want to pollute it too much with unnecessary entries. But what squashing does is that it changes the commit id, so even if the changes were merged it isn't the exact same commit. This will mean that you may encounter situations were your old commits reappear like they were never merged (those 8 ahead). If you look at the files changed it is correct because it is looking at the overhaul changes, but since there was 1 change to a file since you create the branch and the exact same commit id isn't found (your=> e4d7bf4001122ccd4b3fafbcf0673f5a76725c2d, mine => b62cd2c093a8bdf01e90f7ca10716e19e60c7186) it's confused and says that there is a conflict.

But not all your commits appear, so it might be something else. When trying to merge this, Visual Studio created 2 empty commits and the branches visualization showed 2 branches merging, so it might be because we diverged at some point. But your merge should fix that. I might need to do merge on my side, unsure.

Conflicts are inevitable, but you can reduce them by making your branch from the latest of my master. If you do it from my master it will reduce the problems, since like I said above your commit and mine don't match.

Doing a normal merge would result in your commit id staying the same, but would add an additional merge commit every time, polluting the News window. You can see an example of what happens in this repo that I've contributed a couple of time: https://github.com/Card-Forge/forge/commits/master/. Notice all the merge commits? That is what I am trying to avoid, but it is creating our problem.

I am still not a pro with git being unsure how to do some things also, but that is my understanding of the problem. So if you create your merge based on my master it should prevent these kind of problems. You can always reset your master branch to match mine by doing this.

[maforget]

This part from the GIthub docs, might explain what is happening.

When you create a pull request, GitHub identifies the most recent commit that is on both the head branch and the base branch: the common ancestor commit. When you squash and merge the pull request, GitHub creates a commit on the base branch that contains all of the changes you made on the head branch since the common ancestor commit.

Because this commit is only on the base branch and not the head branch, the common ancestor of the two branches remains unchanged. If you continue to work on the head branch, then create a new pull request between the two branches, the pull request will include all of the commits since the common ancestor, including commits that you squashed and merged in the previous pull request.

Because you reused NewUpdatedIcons7 (also NewUpdatedIcons6) and I had already squashed and merged the same commits since, that common ancestor never changed. Now why is that common ancestor for #108 so far in time? It seems to start when you committed to your master by mistake and reverted it (ea9fcc61f347f25eaf5aeb54b9655c87f705f815 & b42b28550f7950be0e65876b3e16d81c88768501). It seems at that point the history diverged and every commit you did reappears. And since I only did squash & merged this kept reappearing.

If I had just merged instead, all your history (merge, reverts, etc) would be part of my history. But it would pollute the commit history. Most solution seem to revolve around rebasing your master or your feature branch on my master to stop this from happening in the future. But the simplest is still what I mentioned git checkout -b NewUpdatedIcons8 upstream/master