https://transfer.sh/

Easy file sharing from the command line
# Upload using cURL
$ curl --upload-file ./hello.txt https://transfer.sh/hello.txt https://transfer.sh/corzR4/hello.txt

# Using the shell function
$ transfer hello.txt
##################################################### 100.0% https://transfer.sh/zuNn92/hello.txt


# Upload from web
Drag your files here, or click to browse.

https://tmpfiles.org/

/TMP/FILES
TEMPORARY FILE HOSTING
You can use our API to automate file uploads.

All uploaded files are automatically deleted after 60 minutes.


Method: POST

Params: file=/path/to/test.jpg

URL: https://tmpfiles.org/api/v1/upload


Example with CURL:

curl -F "file=@/Users/myuser/test.jpg" https://tmpfiles.org/api/v1/upload

#file #sharing #upload #video #image #img #command #line #easy #share
On Local when any Change...
git add -> git commit -> git push origin main

On Server...
git pull origin main

The overall process

People often call this:

Git-based deployment

Deploy via git pull

Or simply: push to GitHub, pull on server

---
on local

# 1. Stage everything you changed
git add .

# 2. Commit with a message
git commit -m "Use MariaDB for TODO storage"

# 3. Push to GitHub
git push origin main

on server

login as owner of the site then
su - cloud # or ssh in as cloud
go version # should also show go1.22.0

cd ~/public_html
git pull
go build -o todo-app

login to root
su

sudo systemctl restart todo-app
sudo systemctl status todo-app

#git #command #common #github
You can totally do that 👍
Think of it like this:

1. Your backup folder = the code you want
2. Your Git repo = the thing connected to GitHub
3. You copy backup → repo, commit, then (maybe) force-push to make GitHub match.

I’ll assume:

* Your WSL project repo is: ~/projects/go/todo-api
* Your backup is somewhere like: ~/backup/todo-api-backup

---

## A. Make your local repo match the backup

1. Go to your repo:


   cd ~/projects/go/todo-api


2. (Optional, but safer) Clean out current files except .git:


   rm -rf *
rm -rf .[^.]* 2>/dev/null # removes dotfiles but keeps .git if it exists


> If rm -rf .[^.]* scares you, skip it and just overwrite files when copying.

3. Copy the backup contents into this repo:


   cp -r ~/backup/todo-api-backup/* .
cp -r ~/backup/todo-api-backup/.* . 2>/dev/null || true


> If your backup also has a .git folder, this will overwrite your current .git.
> That’s fine as long as its origin is still set to https://github.com/kenzastore/todo-api.git.
> We’ll check that next.

4. Check git status and remote:


   git status
git remote -v


You should see:

* lots of changes (or “untracked files”)
* origin https://github.com/kenzastore/todo-api.git

If there is no .git (i.e. git status says “not a git repository”), then:


   git init
git branch -M main
git remote add origin https://github.com/kenzastore/todo-api.git


---

## B. Commit the backup as the new version

git add .
git commit -m "Restore original Go app from backup"


Now your local main branch = backup code.

---

## C. Decide: overwrite GitHub or merge?

### 1️⃣ If you want GitHub to match the backup (overwrite)

This will throw away newer commits on GitHub and replace them with your backup.

git push -f origin main


* -f = force (required because history is different)
* After this, GitHub’s main will look exactly like your local code.

### 2️⃣ If you want to keep GitHub history and merge backup in

Then instead of forcing, you’d first pull and rebase:

git pull --rebase origin main
# resolve any conflicts
git push origin main


But from how you described it (“backup of the original go folder”), you probably want option 1: force-push so everything goes back to that state.

---

## D. Update the server from GitHub

Once GitHub has the backup version:

On the server as user cloud:

cd ~/public_html
git fetch origin
git reset --hard origin/main # make server code exactly match GitHub
go build -o todo-app


Then as root:

systemctl restart todo-app
systemctl status todo-app


Now:

* WSL code = backup
* GitHub = backup
* Server = backup build, running on your domain

---
#git #command #common #github #backup #upload #change #file #wsl #server
- `@<path_to_file_or_directory>`
- Description: Inject the content of the specified file or files into your
current prompt. This is useful for asking questions about specific code,
text, or collections of files.
- Examples:
- @path/to/your/file.txt Explain this text.
- @src/my_project/ Summarize the code in this directory.
- What is this file about? @README.md
- Details:
- If a path to a single file is provided, the content of that file is read.
- If a path to a directory is provided, the command attempts to read the
content of files within that directory and any subdirectories.
- Spaces in paths should be escaped with a backslash (e.g.,
@My\ Documents/file.txt).
- The command uses the read_many_files tool internally. The content is
fetched and then inserted into your query before being sent to the Gemini
model.
- Git-aware filtering: By default, git-ignored files (like
node_modules/, dist/, .env, .git/) are excluded. This behavior can
be changed via the context.fileFiltering settings.
- File types: The command is intended for text-based files. While it
might attempt to read any file, binary files or very large files might be
skipped or truncated by the underlying read_many_files tool to ensure
performance and relevance. The tool indicates if files were skipped.
- Output: The CLI will show a tool call message indicating that
read_many_files was used, along with a message detailing the status and
the path(s) that were processed.

- `@` (Lone at symbol)
- Description: If you type a lone @ symbol without a path, the query is
passed as-is to the Gemini model. This might be useful if you are
specifically talking _about_ the @ symbol in your prompt.

### Error handling for @ commands

- If the path specified after @ is not found or is invalid, an error message
will be displayed, and the query might not be sent to the Gemini model, or it
will be sent without the file content.
- If the read_many_files tool encounters an error (e.g., permission issues),
this will also be reported.

## Shell mode and passthrough commands (!)

The ! prefix lets you interact with your system's shell directly from within
Gemini CLI.

- `!<shell_command>`
- Description: Execute the given <shell_command> using bash on
Linux/macOS or powershell.exe -NoProfile -Command on Windows (unless you
override ComSpec). Any output or errors from the command are displayed in
the terminal.
- Examples:
- !ls -la (executes ls -la and returns to Gemini CLI)
- !git status (executes git status and returns to Gemini CLI)

- `!` (Toggle shell mode)
- Description: Typing ! on its own toggles shell mode.
- Entering shell mode:
- When active, shell mode uses a different coloring and a "Shell Mode
Indicator".
- While in shell mode, text you type is interpreted directly as a shell
command.
- Exiting shell mode:
- When exited, the UI reverts to its standard appearance and normal Gemini
CLI behavior resumes.

- Caution for all `!` usage: Commands you execute in shell mode have the
same permissions and impact as if you ran them directly in your terminal.

- Environment variable: When a command is executed via ! or in shell mode,
the GEMINI_CLI=1 environment variable is set in the subprocess's
environment. This allows scripts or tools to detect if they are being run from
within the Gemini CLI.

#gemini #cli #command #perintah #shortcut