If it's just a UI issue, than this is still unsolved.
Oh I get it, I thought it is only a UI issue... but it actually doesn't send it O_O
I guess. maybe I'll just stash.
Not a big fan of notebooks X git so I attempt to push these less frequently.
The execution uses an older version that is committed.
(I'm working with maria)
essentially, what maria says is when she has a script with uncomitted changes, when executing remotely, the script that actually runs on the remote machine is without the uncomitted changes
e.g.:
Her git status is clean, she makes some changes to script.py and executes it remotely. What gets executed remotely is the original script.py and not the modified version she has locally
WackyRabbit7 you were not entirely correct - the message WARNING! git diff too large to store is actually placed there by Trains SDK instead of the actual diff since the diff is too large and is not sent to the server (which is what I thought initially)
Do you have any idea as to why does that happen SuccessfulKoala55
Hi GleamingGiraffe20 ,
When you run an experiment with uncommitted changes using Trains, Trains will store the uncommitted changes as part of the experiment details (as well as the git repository and commit these changes are based on, of course).
When you clone this experiment and run it using Trains Agent, the agent will pull the required Git repository in the specified commit, and apply the uncommitted changes.
How did you run the experiment for the second time?
I think you are talking about separate problems - the "WARNING DIFF IS TOO LARGE" is only a UI issue, that you can't see hte diff in the UI - correct me if I'm wrong with this
Maria seems to be saying that the execution FAILS when she has uncomitted changes, which is not the expected behavior - am I right maria?
SuccessfulKoala55 when running a changed script without adding committing and pushing the changes are not applied. I do have '# WARNING! git diff too large to store, clear this section to execute without it.' due to unsaved notebook changes.
I guess that's the issue?
Can you get rid of some of these large changes, or are they inherent to your solution?