I've noticed I can edit a Phabricator diff's summary field directly from the web app without having to update the git commit and then updating the diff, but it's not clear to me which changes take precedence. If I Edit Revision via the web app and later land the diff, will those changes get overwritten by the latest git commit message?
You can run arc amend to update the commit message locally based on what phabricator has recorded in differential. I think this is also ran before landing so it should update your local commit message if you change things in the web UI. I don't think the same is true in reverse, however. If you later update the commit message locally after submitting to differential, arc amend will overwrite your changes with the message from differential.
Related
I am deploying a .net application to Azure via a git deployment. However when I launch the deployment I can see it spinning on the website and eventually complete, however it has an older commit message listed and not the most recent commits. I also confirmed in /site/deployments/ that it is using an older commit ID. What would possibly cause the deploy to appear as thought it works but essentially ignore a bunch of commits after a certain point? I also confirmed in the code that it isn't getting updated.
It looks like it is just taking the commit on top (the one deployed a few weeks back) and updating the date of it to be today.
UPDATE: I will also say that this branch was initially an autodeploy and it was failing for permissions for some reason. I have a bunch of instances that have a similar code base and set up and all of them work. Not sure if the fact it was an autodeploy at first is making a difference but why would pushing directly to the remote's master look like it is working but not include updates?
UPDATE 2:
Here are photos of the progression: There is definitely commits after the one it keeps reusing that I cherry-picked from other branches.
we are using Phabricator to performs pre-commit reviews & audits on a mercurial repo. Phabricator does not host the repo, it only observes it.
The project was configured with auto-close, so until recently, pushing all commits of a validated review on the repository automatically closed the related revision.
So far so good.
Today, our admin found out that a php lib was missing and installed it. It seems the deamon never work 'correctly' until now. However, from this moment, all existing reviews have been updated in a way that the very first commit of the review is the only one that can be seen. Any new review is fine until it is closed, where Phabricator writes:
Closed by commit R1:a9a9e1153022: doc: update changelog (authored by vsiles). ยท Explain WhyThu, Sep 7, 5:09 PM
This revision was automatically updated to reflect the committed changes.
(were a9a9e1153022 is the revision of the very first commit, but that's was always the case iirc). Now the whole review only shows the first commit, not all of them.
If we go to the 'History' tab in the review, we can see that Phabricator added an additional 'Diff' with the revision & timestamp of the first commit, after all the diff we pushed. This seems to be the problem. If we modify the history to show all commits but this one, we find back all our review content.
For the moment, my only work-around is to remove the 'auto-close' feature, and close reviews by hand using arc close-revision DXX. There is no more automatic step by Phabricator that messes things up, and the additional diff is not generated by Phabricator.
Can someone explains why Phabricator considers that the review is closed by the first commit, which seems to be the issue here ?
The recommended workflow for Phabricator is to use arc land to push and close the revision. Pushing using mercurial directly may not have the desired outcome because mercurial has no knowledge of Differential revisions, and Phabricator daemons are left to try to reconstruct what they can of the links between revisions and commits after the fact.
We use WPEngine to host WordPress sites and push changes via Git to a staging version of the site - these can then be deployed to the production version via an internal script.
We staged the live site a few days ago and pushed up a number of changes via Git to the staged version.
Accidentally, one user pushed the button to recreate the staged version of the site and all our changes were lost - Git thinks that the local and remote are up-to-date - but of course, the staged version now shows the files in the form they are on the current live site.
Is there a way that we can force push up commits from the last x days or between two set hashes - or some other correct way to notify Git that the changes are no longer in sync?
Thanks!
git push <remotename> <commit SHA>:<remotebranchname> should do the trick, provided <remotebranchname> already exists on the remote. If it doesn't, use git push <remotename> <commit SHA>:refs/heads/<remotebranchname>
Note that this pushes all commits up to and including the commit you choose. If you don't want that to happen, you should first use git rebase -i to re-order the commits.
Note: Picked this from thread on SO : git - pushing specific commit. Check it out for more details.
I have had a similar issue when I have had to restore a site from a backup on WP Engine. What works for me is to just change something in a file.
Add a return at the end of any tracked file (any change at all will do)
Commit change
git push to remote
This should make sure everything matches local, adding/deleting/changing where needed, not just the last commit.
I have a conflict and I am unsure how to resolve it.
The error I get when doing svn udpate is:
Tree conflict on 'wp-content/plugins/eventON'
> local dir replace, incoming dir edit upon update
Select: (mc) keep affected local moves,
(r) mark resolved (breaks moves), (p) postpone,
(q) quit resolution, (h) help:
I do not understand what this is trying to tell me.
I would like it to replace the local version of the web server's plugins/eventON with the version that is in the SVN repo.
Background info:
The error message may be the result of deleting the folder that was being versioned through Wordpress admin panel, and then copying another one in the same location (a bad attempt at updating a plugin while forgetting how SVN works).
I guess that running the update through Wordpress deleted the .svn folders that were present in the plugin (the needed stuff for SVN to work properly).
So you could delete the new, unversioned eventON folder that you have copied in your repo, and run a svn update from one directory above (wp-content/plugins), in order to retrieve the old, versioned plugin.
If it does not work, it may be easier to delete the repository and checkout a fresh version...
Then, you will be able to update your plugin manually through SVN, and commit it.
As long as you already know that you want the server's version and not the local, this shouldn't be too difficult to resolve.
Identify which files are conflicted with svn status.
Since you want to keep the repository's version, you probably want to remove any conflicted files that svn has added from your working copy. They will have an A next to them in the output of svn status. In your case you should probably back them up first, since svn can't get them back for you since they're not in the repo yet. Now use svn delete --force my/fileToDelete. You don't need to delete anything not related to the tree conflict if you have made other changes you want to keep.
Run svn resolve --accept=working my/treeConflictFolder on the remaining folder that is conflicted (it will have a capital C next to it in the output of svn status)
The tree conflict should now be resolved, so you should be able to commit and update normally.
Further reading: http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html
After reading the builtin help, it seems to me that both commads can be used for modifying the workspace to match a certain revision. But I don't understand the differences between update and checkout. Please include some trivial workflows in your answer which show when update/checkout are appropriate.
First major difference is that if you have a remote url set, update will pull first latest artifacts from the remote repository.
Another difference is that if you have uncomitted changes, checkout will not run (unless you force it), whereas update will retain your changes and reapply them. With update you can therefore integrate changes from other users before committing.
So:
Update is what you need when you collaborate on a project, in order to prevent forks.
Checkout lets you deploy a particular version.