I did some changes in my code and after that i did git-review. The changes were on the branch b1 and I created only one commit for these changes. And the changes still unmereged.
After some-days, I deleted this repo from my workspace, and i cloned this repo again.
I see the commit in gerrit, but I don't see on the branch, even after I did git pull --rebase.
What is the reason that I don't see my commit? And how can I fix that (so I will can see it) ?
If you don't see the commit on the branch I assume it's still on reviewing (it wasn't merged yet). In this case, if you want to see the commit locally in a new repository clone, you need to download the commit explicitly.
Go to your Gerrit server;
Go to the change page with your commit (which is on reviewing);
Click on "DOWNLOAD" (on the middle-right of the page);
Choose and copy one of the available commands to download the commit:
All commands will download the commit using different methods, I suggest using the "Checkout" one.
Execute the download command in your local repository.
Related
I am running Odoo 13. I created a new staging branch and used the Odoo.sh web editor to make changes to primary_variables.scss (/src/odoo/addons/web/static/src/scss/primary_variables.scss). However I can't figure out how to commit these changes and push them to my staging branch and merge with the production branch. If I navigate to /src/user and git branch -r I can see all my staging branches however if I navigate to /src/odoo and run git branch -r I can see two branches origin/HEAD and origin/13.0. What am I doing wrong?
No, you can't do that.
Your instance is made up of 4 git repositories. /src/odoo is from https://github.com/odoo/odoo You can change only /src/user
You have to write your own module. That overwrites some CSS values or replaces it fully.
The next link speaks how to load your CSS file. I think you can load your modified file. As it is loaded later the original then it should overwrite original CSS.
https://www.odoo.com/documentation/13.0/reference/javascript_reference.html#assets-management
After cloning a remote git repository and issuing git show --show-signature, it says the signature is good. Then I changed some files and tested the same command, and it still says the signature is good.
What exactly does the above command check? What is the correct way to verify the cloned git is what is meant by the developer?
git show --show-signature does exactly what it says in its manpage:
--show-signature
Check the validity of a signed commit object by passing the signature to gpg --verify and show the output.
You must have imported a repo author's public key before so that GPG
can know where to look for it. You need to read up on a tutorial to
learn how GPG works to fully understand how it works.
Now for the second part of your question, git show without an
explicit commit SHA-1 or object name in general works on current
HEAD. If you just modified some files in your working copy but
didn't commit the changes then HEAD and all other commits in your
repository will stay the same, therefore git show --show-signature
will show you exactly the same as it would after a fresh cloning of
the repository. If you'd decide to commit your changes you will move
your HEAD one commit up but won't modify previous HEAD so git show --show-signature HEAD^ will still show everything is ok.
Commits don't change. git status will report on the status of your worktree; git show is for showing you repository content.
I have an already existing git-svn repo with an ignore paths in my .config file that looks like this:
ignore-paths = ^(?!(Path1/Proj1|Path1/Proj2|Path2/Proj3))
This works well.
Someone added a new project in svn that I now need in my git repo.
If I change ignore-paths to what's below and issue a fetch or a rebase, I never see Path2/Proj4
ignore-paths = ^(?!(Path1/Proj1|Path1/Proj2|Path2/Proj3|Path2/Proj4))
In the past, I've always given up and blasted away my git repo and recreated it. Is there a better way?
After editing the ignore-paths you need to
git svn reset -r <n> -p # where <n> is the SVN revision where the new path was added.
git svn fetch
git rebase # or reset
Reference git-svn(1):
reset
Undoes the effects of fetch back to the specified revision.
This allows you to re-fetch an SVN revision. Normally the
contents of an SVN revision should never change and reset
should not be necessary. However, if SVN permissions change,
or if you alter your --ignore-paths option, a fetch may fail
with "not found in commit" (file not previously visible) or
"checksum mismatch" (missed a modification). If the problem
file cannot be ignored forever (with --ignore-paths) the only
way to repair the repo is to use reset.
Only the rev_map and refs/remotes/git-svn are changed (see
$GIT_DIR/svn/*\*/.rev_map.* in the FILES section below for details).
Follow reset with a fetch and then git reset or git rebase to
move local branches onto the new tree.
In Xcode we pulled someone else's push and merged with local copy. However now the pulled copy has corrupted storyboard. The worst thing is we accidentally pushed those corrupted file to remote repo. Now is there any way I can solve this issue?
we are using SourceTree as our interface to Git.
One of our member has the last working copy as we haven't pulled any corrupted data from server to his copy.
Any potential solution for this situation? Thanks
Sorry but I'm not enough of a Git expert be be able to give you the exact commands, but there are git commands you can enter to revert a file to a specific revision/commit. If you hunt around the web you should be able to find them and revert the file.
You may have to use command line Git.
This may help Reset or revert a specific file to a specific revision using Git?
and this Rollback file to much earlier version using Git
A pull and merge is commited to the history like any other change so you just need to undo that commit. The git command to delete the last commit and restore your working tree to the previous commit is:
git reset --hard HEAD~1
(from Delete commits from a branch in Git)
This change could then be pushed back up to your server.
I was wondering if I right click on a file in the SVN repo browser, does it get permanently deleted? can it be recovered?
This question/answer from the SVN FAQ might interest you :
How do I completely remove a file from the repository's history?
There are special cases where you
might want to destroy all evidence of
a file or commit. (Perhaps somebody
accidentally committed a confidential
document.) This isn't so easy, because
Subversion is deliberately designed to
never lose information. Revisions are
immutable trees which build upon one
another. Removing a revision from
history would cause a domino effect,
creating chaos in all subsequent
revisions and possibly invalidating
all working copies.
The project has plans, however, to
someday implement an svnadmin obliterate command which would
accomplish the task of permanently
deleting information. (See issue 516.)
In the meantime, your only recourse is
to svnadmin dump your repository, then
pipe the dumpfile through
svndumpfilter (excluding the bad path)
into an svnadmin load command.
If it's that hard, there are little chances it can be done easily from Tortoise SVN...
(And it's not the goal of Source Control...)
You'll find that you can only delete from the Repo Browser when you are viewing the HEAD revision. This is identical to deleting a file from your working copy and then checking in the delete. In both cases, you'll be able to restore from the previous revision.
Deleting a file via the repo-browser context menu basically creates a new global revision where just that file was deleted, so it appears in the log as such - you can always revert to that revision to get the file back, or you can just pull it directly from the repository into your working copy.
No... Deleting a file (even using the repo browser) only affects working copies. It would be a pretty lousy revision control system if you couldn't recover a file from the past. It is actually pretty difficult to modify files in a committed revision, even if you have root access to the server.
Doesn't right-click just bring up some sort of menu? And with SVN is that you can always revert anyways.
I deleted a top level directory from Repo Browser by accident and the only way to get it back was the following:
Export the top level folder from a previous version history
Make a new folder in the repository to replace the one deleted.
Add the exported files back to the new directory (same name as previous)
Update the working copy, it will delete and then re-add the same files.
Its annoying but at least the working and repo will be back in sync. The "Revert Changes from this Revision" didnt work for undoing repo deletes, it only reverts in working directory not the "Undo" the delete to the repository.