fedora-magazine

#28 Changed Taiga references to Pagure. Change kanban column names as necesary. Updated some process steps
Closed by rlengland. Opened by rlengland.
rlengland/fedora-magazine workflow  into  master

Download 28.patch

Changed Taiga references to Pagure. Change kanban column names as necesary. Updated some process steps to reflect what is being done. (I hope)

It looks great so far. Thanks!

Hmm, it is saying there is a merge conflict. Are you sure you are working against the latest copy from upstream?

I did the pull about 5 days ago I think. Should have checked. Suggestions for recovery? Or should I just recover the files, delete the branch, and start over?

Well there is the efficient and proper way that requires a little more skill with git. Or there is the clumsy and inefficient way. In truth, either way will get you where you need to go. But if you really intend to do a lot of work with git in the future, it is probably better to do it the more complicated but more efficient way. 🙂

Since I don't know how familiar you are with git, I'll try to start with a high-level overview.

  1. There are three copies/repositories that you are trying to keep in sync.
  2. the "upstream" copy that actually shows up on the website
  3. your "fork" (aka. the "origin" for your local copy)

  4. your local copy on your PC

  5. The "flow" of the data between the three copies is a bit complex.

  6. initially, your fork is a copy of upstream
  7. initially, your local copy is a copy of your fork (the first time you run "git clone")
  8. then
    1. you create a branch (from "master") on your local copy
    2. you "commit" your changes to your local branch
    3. you "push" your branch to your fork
    4. you request that the upstream copy "pull" your branch from your fork and "merge" it into its "master" branch
    5. you pull the updated copy of the "master" branch from the upstream repo directly onto your local "master" branch (THIS IS IMPORTANT)
    6. you push the updated "master" branch from your local copy back to your fork
    7. the "master" branch on all three copies should now be back in sync -- wash, rinse, repeat 🙂

My guess is that you've missed step 5 somewhere along the line. It is probably the most complex step.

Initially, your clone of your fork will not even know the address of the upstream repository. You have to add it the first time. You can see what online repositories ("remotes") your local git repo knows about by entering the following command.

$ git remote -v

Mine shows the following.

$ git remote -v
origin  ssh://git@pagure.io/forks/glb/fedora-magazine.git (fetch)
origin  ssh://git@pagure.io/forks/glb/fedora-magazine.git (push)
upstream    ssh://git@pagure.io/fedora-magazine.git (fetch)
upstream    ssh://git@pagure.io/fedora-magazine.git (push)

If you do not yet have that "upstream" remote (the name is arbitrary; what is important is what it points to), you can add it with the following command.

$ git remote add upstream ssh://git@pagure.io/fedora-magazine.git

Once you have the "upstream" remote defined, you can pull from it to update/re-sync your local copy of "master" so that future branches will not potentially conflict with other changes that have been made upstream. Use the following command to pull the upstream copy of the master branch down and merge it with your local copy of master. Since you never change your master branch directly, there should not be any merge conflicts (it should just be a "fast-forward" merge of whatever PRs the upstream has merged since the last time you ran this command -- including your own changes/PRs that were in your local branches).

$ git checkout master
$ git pull --rebase upstream master

After the above, you can now push your (now up-to-date) copy of "master" back up to your fork (I don't think this is strictly necessary since you never really "pull" from your fork's copy of "master" but I always do it just to keep everything in sync).

$ push

So just keep in mind that there are two upstreams -- "origin" (your fork) and "upstream" (the original repo). You always push your branches to "origin" and you always pull from "upstream". Between your fork and the upstream, data is transferred as pull-requests. So there is a three-node cycle that the data flows around.

Hopefully that makes sense. 🙂
Edited by glb

upstream was pointing to the wrong location and I messed up and lost my changes. Back to the keyboard.

rebased onto ad0a76c3f6c078ae0754c80876e69ceb4a6a2129

Well, your branch is still in your fork. You could always pull it back down. That's the beauty of git -- it keeps lots of decentralized copies of everything everywhere. There is also a way to resolve merge conflicts with git such that you would probably only have to tweak a few characters to fix what you originally submitted. I could try to figure out what was conflicting in your original submission and talk you though how to do that if you want.

Had to recreate the changes. You might check it over again to see if I caught it all.

Okay, I'm confused now. (git does that to me) I thought I had recreated the "workflow" branch after doing the "pull --rebase". Did I not do that from master or something?

I'm still only seeing your first pull request. I think you will have to submit a new PR if you've redone the changes.

Also, just as an exercise, I ran through your merge conflicts. I haven't pushed anything back to the upstream repo. But if you want to try to resolve the original merge conflicts in your original "workflow" branch (which appears to still be in your fork), below is how you would do it.

[/home/gregory/Repositories/fedora-magazine]$ git checkout master
[/home/gregory/Repositories/fedora-magazine]$ git pull --rebase upstream master
remote: Enumerating objects: 22, done.
remote: Counting objects: 100% (22/22), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 12 (delta 6), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (12/12), 1.14 KiB | 83.00 KiB/s, done.
From ssh://pagure.io/fedora-magazine
 * branch            master     -> FETCH_HEAD
   8124e7e..d9489d0  master     -> upstream/master
Updating 44d72aa..d9489d0
Fast-forward
 graphics-sources/fedora-magazine-workflow.svg             | 1606 +++++++++++++++++++++++++++++++++++++-------------------------------------------
 modules/ROOT/assets/images/fedora-magazine-workflow-1.jpg |  Bin 27692 -> 34049 bytes
 modules/ROOT/assets/images/fedora-magazine-workflow-2.jpg |  Bin 37358 -> 46855 bytes
 modules/ROOT/assets/images/fedora-magazine-workflow-3.jpg |  Bin 49045 -> 60025 bytes
 modules/ROOT/assets/images/fedora-magazine-workflow-4.jpg |  Bin 46379 -> 57052 bytes
 modules/ROOT/assets/images/fedora-magazine-workflow-5.jpg |  Bin 36747 -> 47395 bytes
 modules/ROOT/assets/images/fedora-magazine-workflow-6.jpg |  Bin 37290 -> 47910 bytes
 modules/ROOT/assets/images/fedora-magazine-workflow.jpg   |  Bin 151675 -> 200882 bytes
 modules/ROOT/pages/editorial-meetings.adoc                |    8 +-
 modules/ROOT/pages/workflow-edit-image.adoc               |    6 +-
 modules/ROOT/pages/workflow-publishing.adoc               |    5 +-
 modules/ROOT/pages/workflow.adoc                          |    2 +-
 12 files changed, 743 insertions(+), 884 deletions(-)
[/home/gregory/Repositories/fedora-magazine]$ git checkout -b workflow
Switched to a new branch 'workflow'
[/home/gregory/Repositories/fedora-magazine]$ git pull origin workflow
From https://pagure.io/forks/rlengland/fedora-magazine
 * branch            workflow   -> FETCH_HEAD
hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the following
hint: commands sometime before your next pull:
hint: 
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint: 
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
Auto-merging modules/ROOT/pages/workflow.adoc
CONFLICT (content): Merge conflict in modules/ROOT/pages/workflow.adoc
Auto-merging modules/ROOT/pages/workflow-publishing.adoc
CONFLICT (content): Merge conflict in modules/ROOT/pages/workflow-publishing.adoc
Auto-merging modules/ROOT/pages/workflow-edit-image.adoc
CONFLICT (content): Merge conflict in modules/ROOT/pages/workflow-edit-image.adoc
Automatic merge failed; fix conflicts and then commit the result.
[/home/gregory/Repositories/fedora-magazine]$ git status
On branch workflow
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)
Changes to be committed:
    modified:   modules/ROOT/pages/workflow-article-proposal.adoc
    modified:   modules/ROOT/pages/workflow-clarification.adoc
    modified:   modules/ROOT/pages/workflow-review.adoc
Unmerged paths:
  (use "git add <file>..." to mark resolution)
    both modified:   modules/ROOT/pages/workflow-edit-image.adoc
    both modified:   modules/ROOT/pages/workflow-publishing.adoc
    both modified:   modules/ROOT/pages/workflow.adoc
[/home/gregory/Repositories/fedora-magazine]$ vim modules/ROOT/pages/workflow-edit-image.adoc
[/home/gregory/Repositories/fedora-magazine]$ git add modules/ROOT/pages/workflow-edit-image.adoc
[/home/gregory/Repositories/fedora-magazine]$ vim modules/ROOT/pages/workflow-publishing.adoc 
[/home/gregory/Repositories/fedora-magazine]$ git add modules/ROOT/pages/workflow-publishing.adoc
[/home/gregory/Repositories/fedora-magazine]$ vim modules/ROOT/pages/workflow.adoc
[/home/gregory/Repositories/fedora-magazine]$ git add modules/ROOT/pages/workflow.adoc
[/home/gregory/Repositories/fedora-magazine]$ git status
On branch workflow
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)
Changes to be committed:
    modified:   modules/ROOT/pages/workflow-article-proposal.adoc
    modified:   modules/ROOT/pages/workflow-clarification.adoc
    modified:   modules/ROOT/pages/workflow-edit-image.adoc
    modified:   modules/ROOT/pages/workflow-publishing.adoc
    modified:   modules/ROOT/pages/workflow-review.adoc
    modified:   modules/ROOT/pages/workflow.adoc
[/home/gregory/Repositories/fedora-magazine]$ git commit -m 'Updated workflow'
[workflow bbc16de] Updated workflow
[/home/gregory/Repositories/fedora-magazine]$ git status
On branch workflow
nothing to commit, working tree clean
[/home/gregory/Repositories/fedora-magazine]$ git push --set-upstream origin workflow
...

For each of the three files that had conflicts, I used vim to edit the file and manually resolve the conflict. Git shows the conflicts between the '<<<<<<<', '=======', '>>>>>>>' markers. Below is an example from the workflow.adoc file.

<<<<<<< HEAD
An initial proposal lands in the __idea__ state. After some clarification, a specific article goes through 6 states starting as an __article spec__, progressing as __in progress__, __review__, __to edit__, __scheduled__, and finally ends up being __published__. Each step in the workflow has its own page in this documentation that provides guidance.
=======
An initial proposal lands in the __idea__ state. After some clarification, a specific article goes through 5 states starting as an __IDEAS__, progressing as __IN-PROGRESS__, __REVIEW__, __TO-EDIT__, and finally ends up being __SCHEDULED__. Each step in the workflow has its own page in this documentation that provides guidance.
>>>>>>> ad0a76c3f6c078ae0754c80876e69ceb4a6a2129

The top part was from upstream and the bottom part was from your attempted commit. In each of the three files, I just went with the bottom version (your version). So in the above workflow.adoc example, I changed all of that to the following and saved the file and exited the editor.

An initial proposal lands in the __idea__ state. After some clarification, a specific article goes through 5 states starting as an __IDEAS__, progressing as __IN-PROGRESS__, __REVIEW__, __TO-EDIT__, and finally ends up being __SCHEDULED__. Each step in the workflow has its own page in this documentation that provides guidance.

That is how you can use git to resolve merge conflicts. 🙂 You can still give it a try if you want to since your conflicting branch ("workflow") still exists on your fork.

Edit:

I just realized that that last "push" command won't work for you since the "workflow" branch already exists on your fork. I think you could add --force to clobber the existing branch on your fork but that is a bit dangerous. A better solution would probably be to rename the local branch to something like "workflow-second-try".

Edit Again:

I had copy-and-pasted the wrong line into the last code block. It is fixed now.
Edited by glb

Pull-Request has been closed by rlengland
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.