Git Submit Frequently Asked Questions

Answer: you need to put the bad repository in the "Trash". Suppose you did the following:

$ git fork csci:csci099/A1 csci:csci099/$USER/A2
...

You meant to fork csci:csci099/A2 rather than csci:csci099/A1 - to fix this, simply put the bad repository in the Trash:

$ git D trash csci099/$USER/A2
...
$ git fork csci:csci099/A2 csci:csci099/$USER/A2
...

If you had already cloned the incorrect csci:csci099/A2, and not done any work, just delete the directory and clone the new version. Note that the following command is a recursive, forced delete - be careful:

$ rm -rf A2
$

Answer: You need to set the "upstream" to point to the correct destination, your solution repository. For example, suppose you did the following:

$ git fork csci:csci099/A1 csci:csci099/$USER/A1
$ git clone csci:csci099/A1
...
$ cd A1
$ ... edit files, etc. ...
$ git push
$ git push
FATAL: W any csci099/A1 jim DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
$

At this point, you can check where git will send your solution as follows:

$ git remote -v
origin	csci:csci099/A1 (fetch)
origin	csci:csci099/A1 (push)
$

Note that the username, jim in this case, is not present in the destination. To point to the correct upstream, do the following:

$ git remote set-url origin csci:csci099/$USER/A1
$

Doublecheck the setting:

$ git remote -v
origin	csci:csci099/jim/A1 (fetch)
origin	csci:csci099/jim/A1 (push)
$

and now push:

$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 396 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: course = 'csci099'
remote: assign = 'A1'
remote: user = 'jim'
remote: Deadline: 2017-11-30 23:59:59
remote: Now:      2017-11-01 11:03:58
remote: A1 OK - within deadline
To csci:csci099/jim/A1
   b8868f5..5baa588  master -> master
$

Answer: You need to set a new upstream to the correct starting repository, merge it in and then push the result. This is a bit tricky, so please see your instructor if you would addtional guidance.

Suppose you did the following to start an assignment:

$ git fork csci:csci099/A1 csci:csci099/$USER/A2
...
$ git clone csci:csci099/$USER/A2
$ ...
$ cd A2
$ ... edit/hack/crash/etc. ...
$ cat README
GIT repository for csci099/A1
$

Notice that the README says the starting point for this repository was A1, but you are in a directory named A2. You need to set the A2 starting point in as an upstream. First check current upstreams:

$ git remote -v
origin	csci:csci099/jim/A2 (fetch)
origin	csci:csci099/jim/A2 (push)
$

Now add the instructor's upstream:

$ git remote add instructor csci:csci099/A2
$

and check:

$ git remote -v
instructor	csci:csci099/A2 (fetch)
instructor	csci:csci099/A2 (push)
origin	csci:csci099/jim/A2 (fetch)
origin	csci:csci099/jim/A2 (push)
$

Now fetch the instructor's starting version:

$ git fetch instructor
warning: no common commits
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From csci:csci099/A2
 * [new branch]      master     -> instructor/master
$

Now merge the instructor's starting point into your current version of the code:

$ git merge --allow-unrelated-histories instructor/master
Auto-merging README
CONFLICT (add/add): Merge conflict in README
Automatic merge failed; fix conflicts and then commit the result.
$

In this example the README file from the instructor's correct starting point conflicts with the incorrect initial version you forked. If you look at the contents of README you will see that git has marked the specific points of conflict:

$ cat README
<<<<<<< HEAD
GIT repository for csci099/A1
=======
GIT repository for csci099/A2
>>>>>>> instructor/master
$

Text between <<<<<<< and >>>>>>> markers show conflicting lines. The parts between <<<<<<< and ======= come from your version of the file; those between ======= and >>>>>>> come from the instructor's version. For each such part you must decide which is the correct part. In this case, the instructor's README is the one you want, so you would change the file to have the following contents:

GIT repository for csci099/A2

Fix each reported file conflict before proceeding.

Once you are satisfied with your files, you need to tell git by doing a commit, and then push the results to the server:

$ git add .
$ git commit -m 'Fixed starting point to csci099/A2.'
[master 69fef5e] Fixed starting point to csci099/A2.
$ git push
Counting objects: 8, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 906 bytes | 0 bytes/s, done.
Total 8 (delta 1), reused 0 (delta 0)
remote: course = 'csci099'
remote: assign = 'A2'
remote: user = 'jim'
remote: Deadline: 2017-11-30 23:59:59
remote: Now:      2017-11-01 11:27:59
remote: A2 OK - within deadline
To csci:csci099/jim/A2
   b8868f5..69fef5e  master -> master
$

Answer: run the command: ssh csci D list-trash

For example:

$ ssh csci D list-trash
csci099/jim/A2/2017-11-01_11:12:42
csci099/jim/A2/2017-11-01_11:13:34
$

Answer: Yes, if it has not yet been deleted. Continuing the example from the previous question, if you wanted to recover csci099/jim/A2/2017-11-01_11:12:42 you would proceed as follows:

$ ssh csci D restore csci099/jim/A2/2017-11-01_11:12:42
'csci099/jim/A2/2017-11-01_11:12:42' restored to 'csci099/jim/A2'
$

Note that this is server-side only. You would now need to clone the recovered repository.

Answer: Despite being disconcerting, the message about X11 should not be affecting your command. You can silence it by giving the -x argument to the ssh command:

$ ssh -x csci ...