GitHub branch syncing with the master for no obvious reason - r

I'm coding in Rstudio and my workflow is along these lines:
make a new branch using Rstudio's UI
add some code or fix a bug
commit code when I'm satisfied and push to GitHub
merge the new code into the master on GitHub
pull the latest master code from GitHub into Rstudio using it's UI
delete any local/remote branches via command line (because Rstudio doesn't have the functionality and doesn't sync with GitHub when it comes to remote branch deletion)
This might not be the most efficient way of doing things (I'm new to git) but it works well enough except for the problem I'm having. Twice now, seemingly at random, I've created a new branch, worked on it and when I've gone back to check something in the master they are identical. The code changes I've made in the branch have already synced with the master.
This is what the last two lines of the History look like:
git history
independant_erp_norm_regressions is the last branch I merged into the master while preprocess_select_global_pars is the current branch which is syncing to the master unduly.
I'm at a loss as to what is going on because I'm doing the same thing as I usually do and haven't been able to find any similar questions on stackoverflow.
Any help would be greatly appreciated (as well as any ways in which I can streamline my workflow).

Ok thanks for the responses guys, as per Tim's reply I decided to commit the changes made to the new branch via Rstudio's UI and check in command line to see what happened behind the scenes. (After that I thought I would do an entire branch/merge via command line to see if the problem persisted or if it was a Rstudio bug). So just before committing the changes Rstudio's git interface showed that Master and my branch were still in sync up to and including having staged files selected together. After committing I used "git show-branch" in command line and it showed that only the correct branch had a new commit, this was mirrored in Rstudio's Git history interface and after merging via GitHub all is well. So it seems like it was just an Rstudio-git bug of sorts.

Related

Logging into github from Jupyter notebook

I was trying to follow this tutorial do AI image generation on a remote server:
https://youtu.be/tgRiZzwSdXg
And I am getting stuck at this stage:
Apparently it needs me to log into github before it will download the images. Normally this would be trivial but this isn't running in a normal terminal, and I cannot give it any input to log me in. You can see in the attached screen shot with the output right below the code block. Does anyone know how I'm supposed to do this?
I think I've come up with what is going on and how to easily work around it for this case, yet still use git. (The developer offers an non-git route that I reference in the comment below the OP.) You shouldn't need credentials because this is a public repo. Since you have git working on your machine, you should be good. (I can tell git it working because it says it is cloning in that first line below the code in your image instead of saying git isn't recognized.) Try this in Jupyter on your remote machine:
dataset="style_ddim"
#!git clone https://github.com/aitrepreneur/SD-Regularization-Images-Style-Dreambooth-{dataset}.git
!git clone https://github.com/aitrepreneur/SD-Regularization-Images-Style-Dreambooth.git
!mkdir -p regularization_images/{dataset}
!mv -v SD-Regularization-Images-Style-Dreambooth/{dataset}/*.* regularization_images/{dataset}
That version of the steps should work in Jupyter on your remote server without making the cell keep sitting there running and asking you for a username. (Which you cannot provide post-execution because the way the exclamation point sends things to the shell and how Jupyter cells work.)
All I have done is comment out the original line that was getting a specific folder and replaced it with a line cloning the whole repository.
It seems Github treats the ability of getting a specific directory directly as an 'advanced' ability and wants your GitHub credentials for that. Like it would want them for cloning a private repository. Cloning an entire public repository doesn't trigger that need.
What I said in my comments about how you really would provide your credentials on one line holds and the associated security risks, but all that isn't necessary in this case. And you shouldn't need credentials for git cloning public repositories. So the paradigm of just using !git clone ... without credentials inside Jupyter cells should hold if you need to use a similar approach to get something from git. In this case we didn't need to adjust any of the subsequent handling of the cloned contents after; however, that may not always be the case.
Note:
I would have noted that you could just adjust the git clone line earlier if you had included code along with with your image. People trying to help you want it easy. They don't want to type a lot of code that you had as code text and thus could have easily provided in your post. In general, avoid images or only use them as a minor supplement to show behavior. This and more is touched on in How do I ask a good question?. (People trying to help also don't want to go digging elsewhere for code where only a link to a video is provided. Video is farther from code than a screenshot.)
I will say that your use of an image to show the output was definitely justified and helped me match up what I was seeing with yours and know you had git working. With all the symbols and weird characters there it would have been hard to get just right in text only. So why it is best to avoid images, there definitely is a case for 'reserved use' along with text descriptions and code.

Permission problems? Can't see my uncommitted changes in GitAhead

I'm pretty new to the unix world coming from Windows 10 and starting to get comfortable with my new Debian based Voyager OS.
I have pretty much everything up and running but looking for an alternative of Sourcetree I found GitAhead looking promising as it is freeware.
It installed just fine and I could easily connect my works repository and also, fetch changes.
But when it came to my first merge I already had a hard time, finally solving it within PyCharm. Now that I'd like to view and commit my changes with GitAhead, my uncommited changes aren't displayed in GitAheads uncommited changes view.
Is there anything I'm missing? It looks to me like there's some kind of permission problem or why wouldn't GitAhead show me my uncommitted changes?
Edit:
GitAhead GUI Screenshot
Screenshot showing the functionality I'm missing on my other repositories.
This was taken from a fresh repository to demonstrate what my question is about.
As you can see I can select "uncommitted changes", select items on the right side and commit and finally push them. Just not in my companies repositories.
Edit2:
current changelist in my IDE, showing 4 green (new) files
command line # git status, showing 4 added (new) files
GitAhead, showing current branches uncommitted changes
it should display 4 new files and 5 modified, as my IDE and git status do

Commiting to github from R Studio

I am trying to create a website using the R package blogdown. Just have a little problem here. After these functions,
library(blogdown)
new_site()
I tried to commit the folders to Github (have a look)
I don't get anything after pressing "Commit". When I try to check the boxes, nothing happens. When I click "Stage", nothing. What's gone wrong?
Your problem has nothing to do with blogdown but it is a GIT issue. From your picture, it seems, that you did not select and check all the boxes for those files you want to stage. This is necessary to tell GIT which files it should include for your commit:
Check those files you want to prepare for the commit. Only those files which are staged will be included in the commit. (This is the action you missed!)
Add a commit message (this you have already done)
Only now you can click the button "Commit" successfully.
The documentation for blogdown is pretty extensive. In particular, I suggest reviewing the quick example here.
You've generated the template for a new site with blogdown::new_site() but you haven't built it without running blogdown::build_site(). Then the public folder that is generated and populated is the thing that should be committed.

Commit a large number of files in RStudio using GIT panel

In RStudio, if you are dealing with a directory that contains a large number of files, and you want to commit and push the recent changes (that you made on all of them) to your repository, the GUI Git component gets super slow and practically doesn't work. Any idea?
Of course you can ignore the GUI and stick to the command-line Git forever, but if you don't want, a quick jump to the command-line git would solve this problem for now.
The temporary solution that I found is as follows:
Click on the blue-gear icon on the GIT panel, inside RStudio.
Select Shell (a terminal window will pup up!)
Write the add and commit command in the terminal:
{ATTENTION: The following command will commit changes on ALL files! You may want to use what is appropriate for your situation!}
git add -A && git commit -m 'staging all files'
Now you can go back to the GUI Git, and click on push button. All files that you staged in the terminal window, will be pushed up to your repository.
My workaround today was to...
create a man1/ directory in my RStudio project (after force-closing and
relaunching RStudio a few times after I had done something that caused it to hang again),
include man1/ in .gitignore,
move just about everything in man/ to man1/,
delete the .git/index.lock file in the repository,
futz around with RStudio, until it was responsive enough to make the (small) commit of files from man/,
pull and push, so that the remote main was once-again fully synched
copy some files from man1/ to man/, commit these
repeat and rinse of steps 6 and 7, until there's nothing left in man1/
Delete man1/ and its entry in .gitignore
My recipe above isn't one-size-fits-all... for example, you may have run into a "diff is too large" difficulty with RStudio because of a single oversized file, rather than (as I had) with "too many" small files. If you're trying to commit a monstrously-big set of diffs from a single file... you should be including this file in your .gitignore, rather than expecting it to be version-controlled without any difficulty by git. Also, if you're locking up RStudio's Git-interface because of "too many" files being committed simultaneously, your first port of call should I think to commit directories one at a time (but do be sure to push & pull after each commit).
And... I'm not going to complain about this defect in how RStudio interacts with git!
Instead I'll close with some kudos. After just a few days of futzing around with RStudio, I'm finding it to be so much easier than what I remember about hacking on S via emacs in the early 1990s. RStudio handles just about everything (especially the ROxygen documentation workflows) than the emacs/eSS setup that I had been struggling to get fully operational earlier this month.
I'm also impressed with how R has developed since the last time I looked at it -- about 20 years ago! The semantics lurking in corner cases are still very "surprising", to put it mildly ;-) But I do appreciate how it has maintained compatibility with the truly-bizarre and primitive semantics of S while allowing its power-users (which will surely never include me!) to write expressively, elegantly, and with an appropriate balance between concision and the write-only alphabet-soup of APL and its ilk (https://en.wikipedia.org/wiki/Write-only_language)

Using Git in R-studio: cannot stage modified code files

I am new to using git and currently employ the following combination:
Git-Gui v.0.20
R-studio 0.99.489
R 3.22
Bitbucket code repository
Windows 7
Until recently this combination worked fine for pulling and pushing code to the repository. But now I cannot push modified code anymore nor commit it in R-studio.
In R-studio, modified code is marked by a blue M with a checkbox next to it. I cannot check this box for staging, committing and pushing anymore. It literally does not check and react when I click on it.
When I create a new code sniplet which shows as yellow question mark ? I can check and push it, but modified versions cannot be checked anymore.
I have already deinstalled git and R-studio and re-installed but the problem persists. I also created a new repository but the problem occured in the new repository as well. I am a bit clueless where to start looking for a soluation and a web search did not yield many results except this discussion here, which I cannot fully follow because it perhaps does not apply fully to my problem. In any case when I give
> Sys.which('git')
R returns:
git
""
I would appreciate advice where to go from here.
I found an answer to my question. It is a bug in RStudio, albeit not a very well documented one.
When there is a space in the .R file name, it is not possible to push the file through git. Removing the space solves the problem.
See here for an official comment on the Rstudio board dating February 2015. I am using the most recent version of Rstudio and it is not yet fixed there.
Try if the issue persists with:
the latest git for Windows unzipped anywhere you want: PortableGit-2.6.3-64-bit.7z.exe
its path added to %PATH%:
set PATH=%PATH%;C:\path\to\PortableGit-2.6.3-64-bit\bin
its path declare in R-Studio C:\path\to\PortableGit-2.6.3-64-bit\bin\git.exe
R-Studio itself launched from a CMD session where %PATH% already references git.

Resources