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
Related
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.
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.
While I am aware that Hot Restart is in preview, it was for quite a while now and my testing never really worked since the first time I've tried it. I've waited for a few VS studio versions to come up, hoping that my issue will be fixed. Since I've kept an eye on issues and haven't seen something similar, I tend to believe that the issue is locally with my setup.
Here is the situation:
I've enabled Hot Restart in VS and added my account, picked the team (after I was added) and everything went fine without errors. I have a free apple account, but after I was added to a Team I was able to obtain automatic provisioning to work.
I've tried to set the debug build options similar to how the simulator was set
I've disabled device specific build as I saw in the docs that it can create problems.
I've installed iTunes just as specified in the docs and when I connect my device to my Windows 10 PC, I can select it from the list.
So basically it looks like everything is set up. I use for testing an iphone 7 with latest iOS version.
Here is what happens:
I've selected different types of output logs hopeing to catch some error in there that could lead me to find a solution.
when starting to build I can see "Building offline for a local device" and I can see my provisioning file details on "Detected signed identity"
I see no apparent error while it compiles and does its job, no complains about signing
then it gets to the IpaCopyToStagingDirectory and there it starts to copy a bunch of files from bin\Iphone\Debug to Artifacts\app.iOS.dSYM where I get the final error: Could not copy the file bin\iPhone\Debug\\app.iOS.ipa because it was not found
If I go to the bin folder, there are many files, including app.iOS.exe, but indeed there is no ipa file. I also don't know why it has two \ on its path.
Any ideas why is not working?
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)
I created a snapshot view using Rational ClearCase explorer.
After creating it, I set the config specs, environmental variables and later tried compiling my code and got an MVFS error which says:
Unable to determine if the current working directory is in MVFS - no such device or address
When I searched the IBM website for the sake of eliminating this error, I found out that a snapshot view does not use the MVFS !
Why am I getting this error when Snapshot view does not use MVFS?
When this issue got triggered: Actually in our project we were using a ClearCase (8.0.0.7 version). We never had problems when we tried to build our code on the 8.0.0.7 version. It was only after upgrading this version to 8.0.0.15 that the build issue has arisen. The legacy of both old and new ClearCases are baseClearcase
Some more specifications regarding the issue:
The server which we are using is a Windows 2003 server. I am creating a snapshot view in H drive (NTFS drive) as C drive is not available for use in our project, cleaning the previously built files by running the shell script clean_view.sh and then compiling our C code with the ClearCase command clearmake.exe all. Previously we used to follow the same procedure where build used to succeed, but now the same has become an issue.
This question is an extension to the question which I have asked previously. I am re-posting this question as a whole thing again in order to give more clarity about the issue and also for more number of ClearCase experts to chime-in. Kindly do not treat this as a duplicate one or force close it as my issue has not yet been resolved. Also please note that this is the first time I am working with ClearCase.
LINK FOR THE PREVIOUS QUESTION: MVFS error in a snapshot view
Recently there was a development in the solution of this issue !! We escalated this issue to IBM with the help of our client. They suggested us to use Dynamic views and we used them. To our surprise it was working fine and we are able to generate the executables. But the fact still remains that we are not able to use snapshot views !!
NOTE: This comment is just to share my knowledge and experience regarding this issue. :)
While a snapshot view isn't in the MVFS, clearmake has MVFS-specific functionality for build auditing.
You mentioned that the "H" drive contained the snapshot view, is H:
A local or network drive?
A drive letter created via SUBST? In this case, is the parent drive local?
Do builds in dynamic views still work?
Does the C drive exist? Is it remapped in a Terminal Server/Citrix environment?
A caveat: Windows Server 2003 is nearly a year past MICROSOFT'S end of extended support. I would recommend updating the server environment as soon as possible.
Truthfully, issues where a process fails, and the ONLY change is the ClearCase version are usually best handled by contacting IBM instead of using this venue. Not trying to shill or anything, but if it's a clearmake bug, it has to go there anyway...
Additional questions:
If the C: drive is inaccessible on the system, which is what "can't even get the properties" in the comment seems to infer, where is the OS installed? Where does %SYSTEMROOT% point?
If it worked on a different drive, what's different between those 2 drives (H: Failed and R: worked)