Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #129224 > unrolled thread

Re: git

Back to article view | Back to de.comp.os.unix.linux.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: git Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2023-03-11 18:15 +0100
    Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-11 20:33 +0100
      Re: git Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2023-03-11 21:19 +0100
        Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-11 23:23 +0100
          Re: git Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2023-03-12 15:04 +0100
            Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-12 16:41 +0100
            Re: git Thomas Hochstein <thh@thh.name> - 2023-03-12 17:52 +0100
              Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 19:37 +0100
                Re: git Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-03-12 19:22 +0000
                  Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 21:05 +0100
                    Re: git Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-03-13 22:02 +0000
                Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-13 08:09 +0100
                  Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-13 19:05 +0100
            Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 16:53 +0100
              Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-18 09:17 +0100
                Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-19 10:07 +0100
                  Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-19 10:50 +0100
                    Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-19 11:23 +0100
                      Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-19 15:21 +0100
                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-20 07:15 +0100
                          Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-20 07:34 +0100
                            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-20 12:27 +0100
                              Re: git Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-03-20 17:31 +0000
                                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 21:01 +0200
                              Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-20 18:37 +0100
                                Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-23 18:05 +0100
                                  Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-23 20:09 +0000
                                    Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 21:00 +0200
                                  Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-24 18:46 +0100
                                    Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 20:59 +0200
                                      Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-07-18 00:45 +0200
                                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-08-06 13:30 +0200
                                          Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-08-06 15:53 +0200
                                          Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-08-07 18:23 +0200
                                            Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-08-07 18:58 +0200
                                      Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-07-18 18:40 +0200
                          Re: git Christian Garbs <mitch@cgarbs.de> - 2023-03-20 20:35 +0000
                            Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-23 18:06 +0100
                    Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-20 18:41 +0100
                      Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-21 18:30 +0100
                    Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-23 17:45 +0100
                      Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-24 00:11 +0100
                        Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-25 07:40 +0100
                          Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-25 08:38 +0100
      Re: git Stefan Reuther <stefan.news@arcor.de> - 2023-03-12 09:57 +0100
        Re: git Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2023-03-12 10:27 +0100
        Re: git Thomas Hochstein <thh@thh.name> - 2023-03-12 12:29 +0100
          Re: git "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-03-12 14:17 +0100
    Re: git Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-03-12 07:34 +0100
    Re: git Arno Welzel <usenet@arnowelzel.de> - 2023-03-17 16:41 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#129546

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

> Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
> >Marc Haber <mh+usenetspam1118@zugschl.us> wrote:  
> >> Da reicht es doch schon, nach interactive rebase zu fragen und wie
> >> man von einer rewritten History in einem shared branch wieder
> >> arbeitsfähig wird.  
> >
> >Letzteres könnte ich Dir aus dem ff nicht sagen - einfach da ich das
> >"shared branch"-Modell zu vermeiden suche.  
> 
> Ich habe ein Paket mit Übersetzungen, es gibt einen masterbranch, und
> einen "translations", in dem die Übersetzer sich austoben können und
> wenn die sagen, es ist alles fein, wird translations auf master
> rebased und fast forward dort gemergt.

Welcher Teil von "shared branch nicht meine Spezialität" ist unklar?

[toc] | [prev] | [next] | [standalone]

#129550

Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>
>> Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
>> >Marc Haber <mh+usenetspam1118@zugschl.us> wrote:  
>> >> Da reicht es doch schon, nach interactive rebase zu fragen und wie
>> >> man von einer rewritten History in einem shared branch wieder
>> >> arbeitsfähig wird.  
>> >
>> >Letzteres könnte ich Dir aus dem ff nicht sagen - einfach da ich das
>> >"shared branch"-Modell zu vermeiden suche.  
>> 
>> Ich habe ein Paket mit Übersetzungen, es gibt einen masterbranch, und
>> einen "translations", in dem die Übersetzer sich austoben können und
>> wenn die sagen, es ist alles fein, wird translations auf master
>> rebased und fast forward dort gemergt.
>
>Welcher Teil von "shared branch nicht meine Spezialität" ist unklar?

Ich hatte gehofft du hättest eine Lösung für diese Aufgabe.

-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129555

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
>>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>>
>>> Ich habe ein Paket mit Übersetzungen, es gibt einen masterbranch, und
>>> einen "translations", in dem die Übersetzer sich austoben können und
>>> wenn die sagen, es ist alles fein, wird translations auf master
>>> rebased und fast forward dort gemergt.
>>
>>Welcher Teil von "shared branch nicht meine Spezialität" ist unklar?
> 
> Ich hatte gehofft du hättest eine Lösung für diese Aufgabe.

Nun, die naheliegende Lösung ist doch, eben nicht nur einen (und damit
shared) "translations" branch zu verwenden, oder? Zumindest nicht für
die Übersetzer, allenfalls für dich (und damit nicht mehr shared) zum
Sammeln vor dem großen rebase / merge.

Gruß,
Enrik

[toc] | [prev] | [next] | [standalone]

#132841

Enrik Berkhan <Enrik.Berkhan@inka.de> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
>>>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>>>
>>>> Ich habe ein Paket mit Übersetzungen, es gibt einen masterbranch, und
>>>> einen "translations", in dem die Übersetzer sich austoben können und
>>>> wenn die sagen, es ist alles fein, wird translations auf master
>>>> rebased und fast forward dort gemergt.
>>>
>>>Welcher Teil von "shared branch nicht meine Spezialität" ist unklar?
>> 
>> Ich hatte gehofft du hättest eine Lösung für diese Aufgabe.
>
>Nun, die naheliegende Lösung ist doch, eben nicht nur einen (und damit
>shared) "translations" branch zu verwenden, oder? Zumindest nicht für
>die Übersetzer, allenfalls für dich (und damit nicht mehr shared) zum
>Sammeln vor dem großen rebase / merge.

Im konkreten Fall hatte ich einen Freiwilligen, der die Arbeit der
Übersetzer im translations-Branch gesammelt hat, während in master die
Arbeit fleißig weitergegangen ist. Ich glaube, ich hätte das vor dem
merge nicht zu rebasen versuchen sollen und lieber einen merge commit¹
inkaufgenommen.

Grüße
Marc

¹ auch so ein Konzept das ich nie verstanden habe und deswegen zu
vermeiden suche
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129557

Am 20.03.2023 um 12:27 schrieb Marc Haber:
> Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
>> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>>> Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
>>>> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:  
>>>>> Da reicht es doch schon, nach interactive rebase zu fragen und wie
>>>>> man von einer rewritten History in einem shared branch wieder
>>>>> arbeitsfähig wird.  
>>>>
>>>> Letzteres könnte ich Dir aus dem ff nicht sagen - einfach da ich das
>>>> "shared branch"-Modell zu vermeiden suche.  
>>>
>>> Ich habe ein Paket mit Übersetzungen, es gibt einen masterbranch, und
>>> einen "translations", in dem die Übersetzer sich austoben können und
>>> wenn die sagen, es ist alles fein, wird translations auf master
>>> rebased und fast forward dort gemergt.
>>
>> Welcher Teil von "shared branch nicht meine Spezialität" ist unklar?
> 
> Ich hatte gehofft du hättest eine Lösung für diese Aufgabe.

git checkout -B translations origin/translations

Das war bei mir das Kommando, bei dem es bei mir *klick* gemacht hat,
weil man damit - egal, wie man's verbastelt hat - wieder raus kommt.

Ein weiteres Aha-Erlebnis: niemand hindert dich daran, im interactive
rebase einfach noch ein paar 'pick 0815' Kommandos dazuzuschreiben, um
irgendwelche Commits von egal wo auf den aktuellen Branch zu holen.


  Stefan

[toc] | [prev] | [next] | [standalone]

#129636

Stefan Reuther <stefan.news@arcor.de> wrote:
>git checkout -B translations origin/translations

Unverständliche Erklärung, "see git branch for details", das sind 500
Zeilen und ich versteh wieder nur Bahnhof. Ich bin ungefähr so weit
von einem git-Experten enfernt wie Olaf Scholz von einem guten
Kommunikator.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129658

Mahlzeit!

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Stefan Reuther <stefan.news@arcor.de> wrote:

>> git checkout -B translations origin/translations
> 
> Unverständliche Erklärung,

Das legt Dir lokal einen neuen Branch "translations" an
(-b translation) und checkt ihn gleich aus (checkout).

Der Branch wird dabei nicht auf Basis des aktuellen Standes angelegt,
sondern auf Basis von origin/translations (dem Branch "translation" im
remote "origin").

aka: Mach mir einen neuen lokalen Branch, der dem offiziellen
translation-Branch entspricht.


*) klappt nur, wenn lokal kein Branch mehr da ist, der "translation"
   heißt --> git -d translation, git -D translation

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Man soll das Schicksal nicht mit Vorschlägen verärgern. Es legt zuviel
Wert auf seine eigenen Einfälle.              -- Karl Heinrich Waggerl

[toc] | [prev] | [next] | [standalone]

#132840

Christian Garbs <mitch@cgarbs.de> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> Stefan Reuther <stefan.news@arcor.de> wrote:
>
>>> git checkout -B translations origin/translations
>> 
>> Unverständliche Erklärung,
>
>Das legt Dir lokal einen neuen Branch "translations" an
>(-b translation) und checkt ihn gleich aus (checkout).
>
>Der Branch wird dabei nicht auf Basis des aktuellen Standes angelegt,
>sondern auf Basis von origin/translations (dem Branch "translation" im
>remote "origin").
>
>aka: Mach mir einen neuen lokalen Branch, der dem offiziellen
>translation-Branch entspricht.

Ich glaube, das nützt mir erst was wenn ich wieder in die Situation
komme. Ich habe mir das markiert und hoffe dass ich mich daran
erinnere wenn es auftaucht.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129683

Am 23.03.2023 um 18:05 schrieb Marc Haber:
> Stefan Reuther <stefan.news@arcor.de> wrote:
>> git checkout -B translations origin/translations
> 
> Unverständliche Erklärung, "see git branch for details", das sind 500
> Zeilen und ich versteh wieder nur Bahnhof. Ich bin ungefähr so weit
> von einem git-Experten enfernt wie Olaf Scholz von einem guten
> Kommunikator.

"Creates the branch <new_branch> and start it at <start_point>; if it
already exists, then reset it to <start_point>."

Reicht mir als Beschreibung. Das setzt den lokalen `translations` dahin,
wo `origin/translations` gerade ist. Und erweitert: damit kann ich
*jeden* Branch an *jeden* Ort setzen. `git checkout -B master 0815cafe`
setzt meinen `master` auf den angegebenen commit, egal, wie verbastelt
mein Repository ist.

Du kannst natürlich auch `git branch -f translations
origin/translations` machen, kommt wohl auf's selbe raus, aber irgendwie
ist bei mir `git checkout` als Werkzeug zum Anlegen von Branches
hängengeblieben. Hab ich irgendwie nicht hinterfragt, bei SVN nimmt man
ja schließlich `svn cp` dafür...


  Stefan

[toc] | [prev] | [next] | [standalone]

#132839

Stefan Reuther <stefan.news@arcor.de> wrote:
>Am 23.03.2023 um 18:05 schrieb Marc Haber:
>> Stefan Reuther <stefan.news@arcor.de> wrote:
>>> git checkout -B translations origin/translations
>> 
>> Unverständliche Erklärung, "see git branch for details", das sind 500
>> Zeilen und ich versteh wieder nur Bahnhof. Ich bin ungefähr so weit
>> von einem git-Experten enfernt wie Olaf Scholz von einem guten
>> Kommunikator.
>
>"Creates the branch <new_branch> and start it at <start_point>; if it
>already exists, then reset it to <start_point>."

Es hilft in aller Regel nicht, mir die Doku zu zitieren. Die habe ich
schon gelesen und nicht verstanden.

>Reicht mir als Beschreibung. Das setzt den lokalen `translations` dahin,
>wo `origin/translations` gerade ist. Und erweitert: damit kann ich
>*jeden* Branch an *jeden* Ort setzen. `git checkout -B master 0815cafe`
>setzt meinen `master` auf den angegebenen commit, egal, wie verbastelt
>mein Repository ist.

Und was habe ich davon?

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#132857

Marc Haber, 2023-07-17 20:59:

> Stefan Reuther <stefan.news@arcor.de> wrote:
>> Am 23.03.2023 um 18:05 schrieb Marc Haber:
>>> Stefan Reuther <stefan.news@arcor.de> wrote:
>>>> git checkout -B translations origin/translations
>>>
>>> Unverständliche Erklärung, "see git branch for details", das sind 500
>>> Zeilen und ich versteh wieder nur Bahnhof. Ich bin ungefähr so weit
>>> von einem git-Experten enfernt wie Olaf Scholz von einem guten
>>> Kommunikator.
>>
>> "Creates the branch <new_branch> and start it at <start_point>; if it
>> already exists, then reset it to <start_point>."
> 
> Es hilft in aller Regel nicht, mir die Doku zu zitieren. Die habe ich
> schon gelesen und nicht verstanden.

Ein Branch beginnt immer als Kopie eines definierten Stands. Ohne Angabe
wird immer die aktuelle Arbeitskopie verwendet, wie sie gerade ist aber
man kann den Branch auch auf Basis eines anderen Stands anlegen.

Es entsteht ein Zweig, den man später per Merge wieder zum Stamm
zusammenführen kann, aus dem der Branch (Zweig) herausgewachsen ist:

main
  |
  |
  +--- [ branch ] ---> zweig 1
  |                      |
commit                 commit
  |                      |
commit                 commit
  |                      |
  +<----- [ merge ] -----+
  |
  |
  V

Zwischen Stamm (main) und Branch (zweig1) kann man jederzeit hin- und
herwechseln. Nur bei nicht committeten Änderungen muss man entweder
vorher einen commit machen oder "git stash" und später "git stash pop",
um die Änderungen temporär abzulegen und später wieder zurückzuholen.

Bei Rebase dagegen wird versucht, den Hauptstamm direkt auf den Stand
des Zweigens zu bringen, *bevor* die lokalen Änderungen dann erneut
angewendet werden:

main
  |
  |
  +--- [ branch ] --> zweig1
  |                     |
  +<-----+            commit
  |      |              |
commit   |            commit
  |      |              |
commit   +- [ rebase ] -+
  |
  |
  V

Rebase geht natürlich nicht immer - es kann passieren, dass commits, die
im Stamm passiert sind, möglicherweise Änderungen aus dem Zweig
unmöglich machen, weil sowohl im Stamm wie auch im Zweig an den selben
Stellen geändert wurden.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#133329

Arno Welzel <usenet@arnowelzel.de> wrote:
>Ein Branch beginnt immer als Kopie eines definierten Stands. Ohne Angabe
>wird immer die aktuelle Arbeitskopie verwendet, wie sie gerade ist aber
>man kann den Branch auch auf Basis eines anderen Stands anlegen.
>
>Es entsteht ein Zweig, den man später per Merge wieder zum Stamm
>zusammenführen kann, aus dem der Branch (Zweig) herausgewachsen ist:
>
>main
>  |
>  |
>  +--- [ branch ] ---> zweig 1
>  |                      |
>commit                 commit
>  |                      |
>commit                 commit
>  |                      |
>  +<----- [ merge ] -----+
>  |
>  |
>  V

Ja, und wo ist hier der Unterschied zum "normalen" Anfertigen eines
Branches? Kannst Du mir ein Vorher-Nachher-Bild für ein git checkout
-B im Vergleich zu einem git checkout -b malen?

>Zwischen Stamm (main) und Branch (zweig1) kann man jederzeit hin- und
>herwechseln. Nur bei nicht committeten Änderungen muss man entweder
>vorher einen commit machen oder "git stash" und später "git stash pop",
>um die Änderungen temporär abzulegen und später wieder zurückzuholen.

Ich sehe hier die Besonderheit eines mit git checkout -B erzeugten
Branches nicht.

>Bei Rebase dagegen wird versucht, den Hauptstamm direkt auf den Stand
>des Zweigens zu bringen, *bevor* die lokalen Änderungen dann erneut
>angewendet werden:

Auch hier, siehe oben.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#133333

On 2023-08-06 11:30, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Ja, und wo ist hier der Unterschied zum "normalen" Anfertigen eines
> Branches? Kannst Du mir ein Vorher-Nachher-Bild für ein git checkout
> -B im Vergleich zu einem git checkout -b malen?

|       -B <new_branch>
|           Creates the branch <new_branch> and start it at <start_point>; if
|           it already exists, then reset it to <start_point>. This is
|           equivalent to running "git branch" with "-f"; see git-branch(1) for
|           details.


So wie ich das verstehe, ist der Hauptunterschied, dass man bei -b eine
Fehlermeldung bekommt, wenn der Branch bereits existiert, bei -B
hingegen wird der existierende Branch ausgecheckt. Wenn der Branch noch
nicht existiert, wird er in beiden Fällen erzeugt.

Ehrlich gesagt klingt mir -B nach einer Footgun. Ich glaube nicht, dass
man das im (interaktiven) Normalfall verwenden sollte.

        hp

[toc] | [prev] | [next] | [standalone]

#133365

Am 06.08.2023 um 13:30 schrieb Marc Haber:
> Ja, und wo ist hier der Unterschied zum "normalen" Anfertigen eines
> Branches? Kannst Du mir ein Vorher-Nachher-Bild für ein git checkout
> -B im Vergleich zu einem git checkout -b malen?

'checkout -B' macht genau das gleiche wie 'checkout -B', mault aber
nicht, wenn es den Branch schon gibt (sondern überschreibt ihn).

Ich wiederhol mich zwar, aber: der Nutzen dieses Kommandos ist, dass man
sich damit aus jeder Situation befreien kann, in die man versehentlich
gelangt ist. Versehentlich was committed? Versehentlich ungewollt
irgendeinen automatischen Merge ausgelöst? Versehentlich einen rebase
versemmelt? Einfach mit 'git checkout -b $mein_branch $sha1'
zurücksetzen. Man muss nur den gewünschten $sha1 noch irgendwo rumliegen
haben.

Und das ist eben die Lizenz zum hemmungslosen probieren. Im Gegensatz zu
cvs oder svn ist da eben nicht Antreten beim Admin angesagt, damit der
das in der Datenbank revertet, und man muss auch nicht alles löschen und
von vorn anfangen <https://xkcd.com/1597/>.


  Stefan

[toc] | [prev] | [next] | [standalone]

#133367

On 2023-08-07 16:23, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 06.08.2023 um 13:30 schrieb Marc Haber:
>> Ja, und wo ist hier der Unterschied zum "normalen" Anfertigen eines
>> Branches? Kannst Du mir ein Vorher-Nachher-Bild für ein git checkout
>> -B im Vergleich zu einem git checkout -b malen?
>
> 'checkout -B' macht genau das gleiche wie 'checkout -B', mault aber
            ^^                                        ^^
> nicht, wenn es den Branch schon gibt (sondern überschreibt ihn).
>
> Ich wiederhol mich zwar, aber: der Nutzen dieses Kommandos ist, dass man
[...]
> Einfach mit 'git checkout -b $mein_branch $sha1' zurücksetzen.
                            ^^

Irgendwie scheint da die Groß/Kleinschreibung etwas
durcheinandergekommen zu sein, was unpraktisch ist, wenn man über den
Unterschied zweier Flags schreibt, die sich nur dadurch unterscheiden.

        hp

[toc] | [prev] | [next] | [standalone]

#132878

Am 17.07.2023 um 20:59 schrieb Marc Haber:
> Stefan Reuther <stefan.news@arcor.de> wrote:
>> Am 23.03.2023 um 18:05 schrieb Marc Haber:
>>> Stefan Reuther <stefan.news@arcor.de> wrote:
>>>> git checkout -B translations origin/translations
>>>
>>> Unverständliche Erklärung, "see git branch for details", das sind 500
[...]
>> Reicht mir als Beschreibung. Das setzt den lokalen `translations` dahin,
>> wo `origin/translations` gerade ist. Und erweitert: damit kann ich
>> *jeden* Branch an *jeden* Ort setzen. `git checkout -B master 0815cafe`
>> setzt meinen `master` auf den angegebenen commit, egal, wie verbastelt
>> mein Repository ist.
> 
> Und was habe ich davon?

'git checkout -B' bzw. 'git branch -f' ist ein Kommando, mit dem man
sich aus jeder Situation befreien kann, in die man versehentlich geraten
kann, wenn man zum Beispiel mit einem shared branch arbeitet. Zum
Beispiel, wenn 'git pull' einen ungefragten Merge-Commit anlegt.

Mit diesem Kommando ist hemmungsloses Ausprobieren angesagt, bis man den
passenden Workflow gefunden hat. Genau so, wie man hemmungslos
ausprobieren kann, sobald man in der VM den "reset to snapshot" Knopf
gefunden hat.


  Stefan

[toc] | [prev] | [next] | [standalone]

#129563

Mahlzeit!

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:

>>Letzteres könnte ich Dir aus dem ff nicht sagen - einfach da ich das
>>"shared branch"-Modell zu vermeiden suche.
> 
> Ich habe ein Paket mit Übersetzungen, es gibt einen masterbranch, und
> einen "translations", in dem die Übersetzer sich austoben können und
> wenn die sagen, es ist alles fein, wird translations auf master
> rebased und fast forward dort gemergt.
> 
> Aber was dann mit dem rebasten translations-branch, den die
> Translatoren ja ausgecheckt haben?

a) Sie werfen ihren loken translation-Branch weg und branchen sich
   einen neuen vom master.  Wenn alle ihre Änderungen auf dem master
   angekommen sind, geht ja nichts verloren.

b) Sie rebasen ihren lokalen Branch auf den master.  Danach sollte
   dann eigentlich bei ihnen nichts mehr an Änderungen übrig bleiben,
   ihr Branch ist dann gleich dem master (wie bei a) halt). Es kann
   aber sein, dass sie auf dem Weg dahin erst Konflikte manuell
   auflösen müssen, bevor dann am Ende nichts mehr an Änderungen
   überbleibt.

Ich würde a) nehmen.

Am besten kommunizierst Du allen Übersetzern, wenn der
translations-Branch gerebased wurde.  Alternativ merken sie's, wenn
sie nicht pushen können ;-)

Aus dem Bauch heraus würde ich sagen: Wenn die Übersetzer da öfter
Probleme mit haben, sollen sie ihre Übersetzungen bei sich in
Feature-Branches pflegen, die können sie dann einfacher auf einen
aktualisierten translations-Branch bringen (falls sie etwas in Arbeit
haben, was zum Zeitpunkt "rebase auf master" verpasst hat).

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
If the odds are a million to one against something occurring,
chances are 50-50 it will.

[toc] | [prev] | [next] | [standalone]

#129637

Christian Garbs <mitch@cgarbs.de> wrote:
>Aus dem Bauch heraus würde ich sagen: Wenn die Übersetzer da öfter
>Probleme mit haben, sollen sie ihre Übersetzungen bei sich in
>Feature-Branches pflegen, die können sie dann einfacher auf einen
>aktualisierten translations-Branch bringen (falls sie etwas in Arbeit
>haben, was zum Zeitpunkt "rebase auf master" verpasst hat).

Also am ehesten, den "translations" Branch als "da pushe nur ich"
definieren, den Translatoren sagen, sie sollen ihren Branch von
"translations" wegbranchen und dann einen MR stellen.

Wobei ein Merge Request ja wieder kein git-Werkzeug ist.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#129556

Am 19.03.2023 um 10:50 schrieb Dietz Proepper:
> Stefan Reuther <stefan.news@arcor.de> wrote:
>> Am 18.03.2023 um 09:17 schrieb Dietz Proepper:
>>> Arno Welzel <usenet@arnowelzel.de> wrote:  
>>>> Git ist ein Werkzeug, dass man beherrschen sollte.  
>>>
>>> Nun, ich erlaube mir bei Bewerbern gerne, den Begriff git plumbing
>>> oder git porcelain einzuwerfen. "Was ist das?" ist keine gute
>>> Antwort.  
>>
>> Ist das noch relevant?
> 
> Wenn sich wer als mit allen Wassern gewaschener git-Profi ausgeben will?

Naja, ist halt wie wenn man einen Kfz-Profi nach Vergasern für
verbleites Benzin fragt. Oder einen C++-Profi nach den Unterschieden
zwischen C++ nach ARM und ISO 14882:1998. Oder einen Netzwerk-Profi nach
Einkaufstipps für Koax-Kabel.

Die Begriffe waren halt mal relevant, sind es aber nicht mehr.


  Stefan

[toc] | [prev] | [next] | [standalone]

#129576

Stefan Reuther <stefan.news@arcor.de> wrote:

> Am 19.03.2023 um 10:50 schrieb Dietz Proepper:
> > Stefan Reuther <stefan.news@arcor.de> wrote:  
> >> Am 18.03.2023 um 09:17 schrieb Dietz Proepper:  
> >>> Arno Welzel <usenet@arnowelzel.de> wrote:    
> >>>> Git ist ein Werkzeug, dass man beherrschen sollte.    
> >>>
> >>> Nun, ich erlaube mir bei Bewerbern gerne, den Begriff git plumbing
> >>> oder git porcelain einzuwerfen. "Was ist das?" ist keine gute
> >>> Antwort.    
> >>
> >> Ist das noch relevant?  
> > 
> > Wenn sich wer als mit allen Wassern gewaschener git-Profi ausgeben
> > will?  
> 
> Naja, ist halt wie wenn man einen Kfz-Profi nach Vergasern für
> verbleites Benzin fragt. Oder einen C++-Profi nach den Unterschieden
> zwischen C++ nach ARM und ISO 14882:1998. Oder einen Netzwerk-Profi
> nach Einkaufstipps für Koax-Kabel.
> 
> Die Begriffe waren halt mal relevant, sind es aber nicht mehr.

Im obigen Fall dachte ich an jemanden letzten Herbst, der "git seit
2007" verwendet.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web