Consider the following workflow:
make some changes
git add . && git commit -am 'update 1'
arc diff, now local and phabricator code review are in sync
make some further changes and git commit -a --amend --no-edit
arc land and the local amended (unreviewed) changes are happily accepted by Arcanist and gets merged to master.
Apparently, if I don't do --amend in step 4 and create another commit, arc land would fail complaining a mismatch. But I would like to configure Arcanist so that with --amend arc land can fail as well. Is this possible?
It turns out the arc command I am using is monkey patched by my employer and there is a bug in the patch.
Related
I've a remote repository let's call it subrepo. I want to include it as subtree in local repository, let's call it mainrepo. I'll put subrepo under the path 'subrepofold/'.
I added as usually the remote using:
git remote add subrepo git#remote.subrepo.git
On mainrepo I've only a branch (master). I added and committed all:
git add --all
git commit -m "message"
git status
On branch master
nothing to commit, working directory clean
git diff-index HEAD --exit-code --quiet
Give me no output. Running:
git subtree pull --prefix="subrepofold" subrepo master --squash
I get the following message:
Working tree has modifications. Cannot add.
I know it seems to be the exact problem described here, but none of the replies seems to resolve the problem.
I am currently struggling with getting Rstudio to work with my git repositories. When I set up a new project and assign the git repository, the branch is set on Master and the commit, pull, and push buttons are all active. Everything works just fine. Then, at some point the branch is switched to (No Branch) and the commit, pull, and push buttons are greyed out (shown below). This happens to every single git project I make. Works at first then is greyed out.
I am still able to use git commands from Shell, but the GUI interface is not working.
I have spent some time looking through customer support forums and Googling the problem. One site that I found (https://www.r-bloggers.com/things-i-forget-pushpull-greyed-out-in-rstudio/) indicated that there is an issue with the configuration list. However, when I do git config --list, I find that I do have branch.master.remote=origin and branch.master.merge=refs/heads/master at the bottom of the configuration.
I also attempted a git push -u origin master, but that did not work either.
I use RStudio and github daily, and I would be so pleased if the GUI interface was working properly again.
I would be very grateful if someone could help me problem solve this issue.
EDIT: I am using OSX 10.9 Mavericks and Rstudio Version 0.99.903.
I had a similar problem with a repo I had already configured locally and pushed and pulled from/to it using CLI (although I didn't have the problem of being detached from a branch) and I solved it by doing the following:
Open your console and navigate to your repo
Make some commit
Make a push using -u (i.e. --set-upstream) flag, eg: git push origin master -u
Open Rstudio (or restart it if it was open while performing the previous step) and you'll see the push and pull icons are no longer greyed out.
Then, at some point the branch is switched to (No Branch) and the commit, pull, and push buttons are greyed out (shown below).
That is typical of a detached HEAD branch: see "Why did my Git repo enter a detached HEAD state?".
Revert to the command-line and check your git status.
You can easily recover from this by a checkout of a branch.
Or by forcing a branch to your current detached commit
git branch -f branch-name HEAD
git checkout branch-name
Then switch back to RStudio: all options should be available again.
As commented:
Tt turns out to be an RSA key issue.
The wrong key was in the Rstudio Config, which explains how Shell would work but not the Rstudio interface.
I just wanted to provide an update in case anyone in the future had a similar problem. While the answer provided earlier resulted in another temporary fix, I ultimately had to wipe my hard drive; reinstall the operating system; reinstall git, R, RStudio, and reconnect to my Github account before it would consistently work.
My solution may have been a bit overkill, but I have not had an issue with it since.
I had the same issue today and found this post. I am going to share how I solve it:
on terminal (Git) type the following:
$ git config --global user.name
(it should return your Github username)
if username isn't correct just type
$ git config --global user.name "correct_username"
then type
$ git config --global user.email
(it should return an email associated to your GitHub account)
I found a typo in my email and fixed it by typing
$ git config --global user.email "correct_email"
Then I added the origin (this you get it from GitHub)
$ git remote add origin https://github.com/my_username/my_repository.git
Then I setup the branch, most used ones are main and master, in my case it is main
$ git branch -M main
then I pushed from the terminal
$ git push -u origin main
after that my pull and push buttons are active.
I hope this can save some time for others.
I am seeing a strange behaviour, I don't know if it is a bug or a feature.
From machine #1 I do git reset --hard someCommit && git push -f. The reset is then propagated to all machine (I can see the change by doing a git pull or git logfrom another machine).
From machine #2 that runs JGit I perform: git.pull().call() but the reset is not applied and the files on disk are not changed. Also git.log().call() does not point to the reverted commit.
What am I doing wrong?
Like Tim described, you likely need to force fetch on the other computers.
The return value of PushCommand::call() will tell you if and why the push did not succeed.
To force pull in JGit, follow this example:
git.fetch()
.setForce( true )
.setRefSpec( new RefSpec( "refs/heads/someBranch:refs/remotes/origin/someBranch" ) )
.call();
git.reset()
.setMode( ResetType.HARD )
.setRef( "someBranch" )
.call();
I believe that the git.pull.call() command is being rejected. You executed the following commands:
git reset --hard someCommit
git push -f
The first one should completely reset the branch to someCommit. The second one force pushes the reset branch to the remote, rewriting the history of the branch in the process. The keyword here is -f which is short for --force.
Because you rewrote the history of this branch, other computers will no longer be able to do a simple git pull because the base of the branch has changed. So I believe that your JGIT call to git.pull().call() is failing with an error. To fix this, you need to "force" pull the branch on the other computers:
git fetch --all
git checkout someBranch
git reset --hard origin/someBranch
In darcs, what if I want to re-order to the top (or just throw away) a patch which other patches depend on (i.e., change the same file)?
In git, I'd simply do a git rebase -i <UNTOUCHED-REVISION> and reorder or throw away some changes; then git would in a dumb fashion try to apply the old changes to the new variant of the tree one by one, and ask me to resolve the arising conflicts.
In darcs, I see no way to force it to ignore the dependencies between patches. If I obliterate or suspend (or unrecord) a patch which other patches depend on, darcs refuses to do it. (Because it wants to behave in a clever manner.)
I had the following plan to do this:
suspend the dependent patches (those which depend on the patch
which I want to re-order or throw away).
somehow unrecord the patch to re-order and save it somewhere else
(perhaps in another "darcs branch", i.e., a copy of the repo) and revert
the changes to the working directory so that the working directory is
clean.
after that, unsuspend the suspended patches up to the state
where I want to insert the re-ordered patch. (Resolving all arising conflicts.)
apply the saved patch (perhaps, by pulling from the saved "branch",
i.e., the copy of the darcs repo which I have saved on step 2).
unsuspend all remaining patches. (Resolving all arising conflicts.)
Here are some notes on how all this has proceeded.
1. suspend the dependent patches
If among the patches dependent on the patch you want to re-order there
is a single "minimal" one (according to the graph of dependencies),
then you simply give the command to suspend it (and after that there
will be no "active" patches which would depend on the re-ordered
patch):
darcs suspend -h <MINIMAL-DEPENDENT-HASH>
(and confirm the suspension of all other dependent patches).
Of course, if there are several minimal dependent patches, you have to
suspend each (each's subgraph will be asked for suspension).
2. save and revert the unwanted changes
Preparation
First, I look at the changes I'm going to work with:
darcs diff -h 61fbb4aeac9e69cf30d232eda274c18194d7a8d9 --diff-command='emacs -f ediff-directories-with-ancestor-command %1 %2'
(The change was logically simple, but diff showed it in a
complicated way, so, here, I launched Emacs's ediff via a special
function I had written for this purpose.)
I saw that the change included some cleanup and the addition of a new
feature. So, the plan is now to split it: unrecord the patch, and record two
patches instead.
darcs unrec -h 61fbb4aeac9e69cf30d232eda274c18194d7a8d9
Now, I can view and (perhaps, work) with the changes with ediff, too.
darcs diff --diff-command='emacs -f ediff-directories-with-ancestor-command %1 %2'
First, I record the cleanup patch (selecting and editing only the
relevant hunks). Then, the added action:
darcs rec -m 'examples/Process.hs: code cleanup (present as a sequence of actions and error handling)'
darcs rec -m 'examples/Process.hs: print the C program (from the AST) after the check (as gcc -E does)'
Saving as a patch (a variant)
One could use darcs obliterate -o or -O to save the obliterated
change, and then restore it with darcs apply (according to that advice).
But I proceeded differently:
Saving as a branch (a variant)
Cloning didn't work for a repo with suspended patches:
~/TOOLS/prog/language-c $ darcs clone . ../language-c_printAST
darcs failed: Can't clone a repository with a rebase in progress
~/TOOLS/prog/language-c $
So, let's make a copy (and check whether we would be allowed to pull
from it):
~/TOOLS/prog/language-c $ cp -a ../language-c ../language-c_printAST
~/TOOLS/prog/language-c $ darcs pull ../language-c_printAST
darcs failed: Incompatibility with repository /home/imz/TOOLS/prog/language-c_printAST:
Cannot transfer patches from a repository where a rebase is in progress
~/TOOLS/prog/language-c $ cd ../language-c_printAST/
~/TOOLS/prog/language-c_printAST $ darcs rebase obliterate
<...>
Really obliterate all undecided patches? y
Rebase finished!
~/TOOLS/prog/language-c_printAST $ cd ../language-c
~/TOOLS/prog/language-c $ darcs pull ../language-c_printAST
HINT: if you want to change the default remote repository to
/home/imz/TOOLS/prog/language-c_printAST,
quit now and issue the same command with the --set-default flag.
No remote patches to pull in!
~/TOOLS/prog/language-c $
Ok, good, so we will pull from that repo later.
Revert the changes
Throw away the unwanted (or re-ordered) patch:
darcs obliterate
3. Unsuspend the patches that should come before it
It's a good idea to make a backup copy of the repo at this point, because you
might screw something up during the unsuspending and resolving conflicts.
Unsuspend the patches that should come before it. (Unfortunately,
external merge tool is not supported in unsuspend.) It's better to
unsuspend them one by one as you'll have to resolve the conflicts
caused by each one and amend the patch:
darcs rebase unsuspend
# resolve conflicts
darcs amend
# repeat for the remaining patches you want to have
4. Apply the saved patch
darcs pull ../../language-c_printAST
# resolve conflicts
darcs amend
5. Unsuspend all remaining patches.
(Again, it's better to do this one by one.)
darcs rebase unsuspend
# resolve conflicts
darcs amend
# repeat for the remaining patches you want to have
(For some reason, on the first attempt, I lost a hunk in the last
unsuspended patch. But I repeated everything in a copy of the backup
copy, and there I reached the wished final state.)
I've run git init and made a mistake selecting the first branch. Now I want to rerun it to change the settings, but it never asks the first question again.
Which branch should be used for bringing forth production releases?
- develop
Branch name for production releases: [] develop
Which branch should be used for integration of the "next release"?
Branch name for "next release" development: [develop] ^C
Lymnaea:boxes (develop) $ git flow init
Which branch should be used for integration of the "next release"?
Branch name for "next release" development: [develop]
Production and integration branches should differ.
How can I undo the first init run so that I can set the branch to master?
In the end I found the answer in this question. It's not entirely a duplicate, so I'll leave this here for the next person that cannot find the right keywords.
git flow init -f # will force re-initialization
If you want to do it manually, you can use git config -e.