Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Untypos #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Untypos #6

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion advanced.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1186,7 +1186,7 @@ Version im aktuellen Working Tree) sowie `Stashed Changes`
[IMPORTANT]
============
Sollten Sie versucht haben, einen Stash mit `git stash
pop` anzuwenden, wird der Stash 'nicht' automatisch gelöscht.
apply` anzuwenden, wird der Stash 'nicht' automatisch gelöscht.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Das ist schon korrekt so, aber vielleicht missverständlich formuliert. Bei git stash apply wird der Stash nie gelöscht. Wenn man aber normalerweise mit git stash pop arbeitet, und dann in einen Konflikt gerät, dann hat man Konfliktmarker und löst den Konflikt – der Stash verschwindet aber nicht automatisch. Vermutlich ist es am klarsten, wenn Du in den Satz “im Konfliktfall” einbaust.

Sie müssen ihn explizit mit `git stash drop` löschen.
============

Expand Down
2 changes: 1 addition & 1 deletion workflows.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -446,7 +446,7 @@ essentiell die gleiche Änderung einbringen, die gleiche ID.
In der Regel wird `git cherry` eingesetzt, wenn sich die Frage
stellt: Welche Commits wurden schon in den Integrations-Branch
übernommen? Dafür wird das Kommando `git cherry -v <upstream>
<topic>` verwendet: Es listet alle Commits auf `<topic>` auf,
<topic>` verwendet: Es listet alle Commits aus `<topic>` auf,
und stellt ihnen ein Minus (`-`) voran, wenn sie schon in
`<upstream>` sind, ansonsten ein Plus (`+`). Das sieht z.B.
so aus:
Expand Down