Προς το περιεχόμενο

Προτεινόμενες αναρτήσεις

Δημοσ.

Κάνεις diff στα backups (τα οποία ούτε αυτά τα κρατάς manually, αλλά automated). Ακόμα κι αυτό όμως είναι μάλλον άχρηστο για πολύ μικρά projects, γιατί πας απευθείας στον debugger.

 

Και αυτό ακριβώς είναι που εννοούσα νωρίτερα ότι καταλήγεις να κάνεις παραπάνω δουλειά για χειρότερο αποτέλεσμα. Ναι, ακόμα κι αν η παραπάνω δουλειά είναι μεγέθους να μάθεις ποιό είναι το command line option που κάνει το backup incremental. Φυσικά αν έχεις diffs και χάσεις το full backup πάνω στο οποίο πατάνε συγχαρητήρια, αλλά εν πάσει περιπτώσει δε με ενδιαφέρει να αναλύσω αυτό το θέμα -- απλώς να επιστήσω την προσοχή ότι αν τα βάλεις κάτω "ίσως" τελικά το git να ήταν καλύτερη επιλογή.

  • Απαντ. 106
  • Δημ.
  • Τελ. απάντηση

Συχνή συμμετοχή στο θέμα

Δημοσ.

Θεωρητικά δεν κάνεις commit αν δεν μαζευτεί ικανός αριθμός αλλαγών.

Στο βωμό του να έχεις πάντα το τελευταίο λόγο (ειδικά αν πρόκειται να την πεις στον defacer) πολλές φορές εκτίθεσαι. Αυτό το σκέφτηκες πριν το γράψεις ?

 

Λόγω του client-server μοντέλου και λόγω του ενός "branch" - trunk το κλασικό πρόβλημα με τα cvs, svn ήταν ότι όταν πήγαινες να κάνεις κάποιο "push", κάποιος άλλος είχε ήδη πειράξει κάποιο ίδιο αρχείο με εσένα με αποτέλεσμα να δημιουργούνται διενέξεις. Έτσι έπρεπε να κάνεις fetch τις αλλαγές των άλλων, να επιλύσεις τις διενέξεις και να ξανακάνεις push γρήγορα πριν στείλει κάποιος άλλος και έχεις πάλι διενέξεις.

 

Για αυτό το λόγο, πολλοί devs συνήθιζαν να μην στέλνουν τίποτα "μέχρι να μαζευτεί ικανός αριθμός αλλαγών" ώστε να μην χρειάζεται να επιλύουν διενέξεις 30 φορές.

 

Ένα βασικό πλεονέκτημα των DVCS είναι ακριβώς ότι δεν υπάρχει αυτό το overhead και δεν είσαι υποχρεωμένος να περιμένεις αλλά μάλιστα συστήνεται από τους πάντες να μην περιμένεις αλλά να έχεις μικρά και διακριτά commits.

Δημοσ.

Όπως γράφω και στο προηγούμενο ποστ μου, η δική μου άποψη κλίνει προς "παν μέτρο άριστο" παρά προς το "τυφλή εφαρμογή πασπαρτού παντού και πάντα".

 

Μην ξεχνάς πως υπάρχει κι ένα αρχικό τμήμα (μικρά πρότζεκτ) που το μόνο που χρειάζεται είναι ένας debugger και τίποτε άλλο.

 

PS. Btw, incemental backup κάνουν νομίζω όλοι οι στοιχειωδώς αξιοπρεπείς editors/ide.


Στο βωμό του να έχεις πάντα το τελευταίο λόγο (ειδικά αν πρόκειται να την πεις στον defacer) πολλές φορές εκτίθεσαι. Αυτό το σκέφτηκες πριν το γράψεις ?

Λόγω του client-server μοντέλου και λόγω του ενός "branch" - trunk το κλασικό πρόβλημα με τα cvs, svn ήταν ότι όταν πήγαινες να κάνεις κάποιο "push", κάποιος άλλος είχε ήδη πειράξει κάποιο ίδιο αρχείο με εσένα με αποτέλεσμα να δημιουργούνται διενέξεις. Έτσι έπρεπε να κάνεις fetch τις αλλαγές των άλλων, να επιλύσεις τις διενέξεις και να ξανακάνεις push γρήγορα πριν στείλει κάποιος άλλος και έχεις πάλι διενέξεις.

Για αυτό το λόγο, πολλοί devs συνήθιζαν να μην στέλνουν τίποτα "μέχρι να μαζευτεί ικανός αριθμός αλλαγών" ώστε να μην χρειάζεται να επιλύουν διενέξεις 30 φορές.

Ένα βασικό πλεονέκτημα των DVCS είναι ακριβώς ότι δεν υπάρχει αυτό το overhead και δεν είσαι υποχρεωμένος να περιμένεις αλλά μάλιστα συστήνεται από τους πάντες να μην περιμένεις αλλά να έχεις μικρά και διακριτά commits.

 

Νομίζω πως μάλλον εσύ στη βιάση σου να μου την πεις χάνεις τον ειρμό. Αν δεν απατώμαι ο Kercyn ρώτησε για αλλαγές που έχουν να κάνουν με μικρο-ασήμαντες διορθώσεις και πως να τις χαρακτηρίζει όταν κάνει commit. Και του απάντησα πως μια λογική είναι να μην κάνει commit μέχρι να γίνουν σημαντικές οι αλλαγές.

Δημοσ.

Αν δεν απατώμαι ο Kercyn ρώτησε για αλλαγές που έχουν να κάνουν με μικρο-ασήμαντες διορθώσεις και πως να τις χαρακτηρίζει όταν κάνει commit. Και του απάντησα πως μια λογική είναι να μην κάνει commit μέχρι να γίνουν σημαντικές οι αλλαγές.

 

Και μετά έχεις στο ίδιο commit σημαντικά και ασήμαντα πράγματα και ψάχνεις να βρεις με το μάτι που είναι τι, αντί να έχεις ένα commit message "ασήμαντα πράγματα" και ένα "σημαντικά πράγματα". Κατ' επέκταση git log | grep ποτέ δε σε συμπάθησα κλπ.

Δημοσ.

Και μετά έχεις στο ίδιο commit σημαντικά και ασήμαντα πράγματα και ψάχνεις να βρεις με το μάτι που είναι τι, αντί να έχεις ένα commit message "ασήμαντα πράγματα" και ένα "σημαντικά πράγματα". Κατ' επέκταση git log | grep ποτέ δε σε συμπάθησα κλπ.

 

Αυτή είναι μια άλλη λογική. Αν αναπτύσσοντας κώδικα μπορείς με σχετική συνέπεια να διαχωρίζεις τις διορθώσεις/προσθήκες σου σε σημαντικές και ασήμαντες, τότε by all means use it. Συνήθως όμως οι σημαντικές & ασήμαντες αλλαγές είναι mixed up.

Δημοσ.

Ρε και 2 .c files να έχεις το "θράσος" να τα αποκαλείς project, δεν καταλαβαίνω τι είναι πιο απλό ή τι είναι πιο εξυπηρετικό από το να πατήσεις ένα git init. Μόλις ξεπεράσεις την (αρχικά ομολογουμένως μεγάλη) καμπύλη εκμάθησης του git, δεις και λίγο GitHub, νομίζω πως έχεις το feeling πως ότι χρησιμοποιούσες μέχρι τώρα είναι παιδικό.

Πιο απλό, λιτό κι απέριττο απ΄ το git δεν έχει, πέρα απ το απλό versioning και απίθανο branching του source, συνάμα έχεις functionality όπως το να κάνεις ignore files απ' το source σου (ναι, ακόμα και τo binary που βγάζουν δύο files), cherry pick, το rebase, το bisect και 1002 καλούδια που σε βοηθάνε να κάνεις φύλο και φτερό το source, και να διαχειριστείς τα files σου, που ίσως να μη χρειαστεί να διαβάσεις/κατανοήσεις ποτέ τι κάνουν, but they're there και περιμένουν να τα μάθεις. Δηλαδή μόνο πιο εύκολη μπορείς να κάνεις τη ζωή σου, αν θελήσεις (και των άλλων...)

Δηλαδή αν σου ζητήσει κάποιος να δει το "μικρό" σου project τι θα κάνεις, θα στείλεις e-mail το .zip αρχείο;; Great help. Αυτό μου μοιάζει σαν κάτι που κάνανε παλιά στο Texas. But hey, that's just me.

Όσον αφορά τα commits, εγώ προσωπικά πιστεύω καλό practise είναι ένα commit να αντιπροσωπεύει μία λογική ενότητα δουλειάς, χωρίς να ξεφεύγει από τα λογικά πλαίσια το μέγεθος. πχ.

- You fixed a typo και το μόνο που έκανες edit ήταν ένας char.
- Έκανες edit 18 class files γιατί άλλαξες το signature ενός interface.
- Πρόσθεσες ένα ολόκληρο folder με files, το source από ένα παλιό project που έχει functionality που θες να usareis.

Είναι και ένας πάρα πολύ καλός τρόπος αυτός να θυμηθείς πιο εύκολα τι έκανες την τελευταία φορά που δούλευες το project και να συνεχίσεις να κάνεις δουλειά πιο γρήγορα. Ας πούμε πέθανε το hamsteraki σου και δεν έγραψες για 5 μέρες κώδικα.

Last commit message: Groundwork for suberb feature #27 (files edited/files added). Αααα αυτό έκανα εεε; Γαμώ!

Vs.

ΜySmallProjectThatSnobsVCS.zip. Χμμμμ...;

Joking aside, git rulez.

  • Like 1
Δημοσ.

Αυτή είναι μια άλλη λογική.

Αυτό δεν είναι λογική, είναι επιχείρημα.

 

Συνήθως όμως οι σημαντικές & ασήμαντες αλλαγές είναι mixed up.

 

Συνήθως όχι (discipline) αλλά και να είναι στο git υπάρχουν τόσο πολλές δυνατότητες για να τα ξεμπλέξεις (ακόμα και κατόπιν εορτής!) που αυτό δεν ισχύει σαν επιχείρημα.

 

Πέρα από το κλασικό τη στιγμή που συνειδητοποιείς ότι πας να κάνεις κάτι τέτοιο σταματάς επιτόπου και κάνεις κάτι του στυλ stash/branch/commit/checkout/rebase/pop υπάρχει επίσης το interactive staging και το interactive rebase.

Δημοσ.

Τι ήθελα και είπα ότι βαριόμουν να κανω git repo, εκτροχιάστηκε το thread :P

 

Όσον αφορά τα commits, εγώ προσωπικά πιστεύω καλό practise είναι ένα commit να αντιπροσωπεύει μία λογική ενότητα δουλειάς, χωρίς να ξεφεύγει από τα λογικά πλαίσια το μέγεθος. πχ.

+1 σε αυτό. Συχνά κάνω commit τμήμα των συνολικών αλλαγών αντί για όλες μαζί, ώστε να είναι λογικά ταιριαστές.

  • Like 1
Δημοσ.

Τι ήθελα και είπα ότι βαριόμουν να κανω git repo, εκτροχιάστηκε το thread :P

...

 

Είναι απλά τα πράγματα. Από τη στιγμή που η επιλογή σου είναι συνειδητή και ενημερωμένη (educated), δεν έχεις να απολογηθείς σε κανέναν. Πάλι καλά που δεν σου είπαν να φτιάξεις και makefile και τίποτα pkg-config για τον ναρκαλιευτή.

 

Όποιος πραγματικά ενδιαφέρεται να δει τον κώδικά σου θα τον δει, είτε τον δημοσιεύσεις σε zip, είτε μέσα σε spoiler στο φόρουμ, είτε με οποιονδήποτε άλλο τρόπο.

 

Επίσης, git init μπορείς να κάνεις ανά πάσα στιγμή (τουτέστιν :P αν και όποτε αισθανθείς την ανάγκη πως το project σου το χρειάζεται από την τρέχουσα μορφή του κι έπειτα).

Δημοσ.

Επίσης, git init μπορείς να κάνεις ανά πάσα στιγμή (τουτέστιν  :P αν και όποτε αισθανθείς την ανάγκη πως το project σου το χρειάζεται από την τρέχουσα μορφή του κι έπειτα).

Νομίζω πως το συγκεριμένο έχει ήδη ανασκευασθεί...Δεν είναι και αυτό απλά μια άποψη, υπάρχει και η έννοια του history. Αν περιμένεις να μεγαλώσει, τότε έχεις χάσει αρκετή δουλειά απ' το history του project.

 

Πρώτα απ' όλα δε μπορείς να βάλεις versioning εκ των υστέρων. Επομένως γιατί να πάρει κανείς το ρίσκο να ξεπεράσει ...

 

Υ.Γ

Δεν του είπε κανείς τι να κάνει.

Δημοσ.

@All CowsEatGrass:

 

Δεν ξέρω τι εννοείς με το "έχει ανασκευασθεί", ούτε ξέρω τι εννοεί ο defacer στην παράθεση που έχεις κάνει. Ξέρω όμως πως μπορείς να ξεκινήσεις το version control όποτε θέλεις. Δεν χρειάζεται να το κάνεις από την αρχή.

 

Από εκεί και πέρα, γιατί θεωρείς αναγκαία την ύπαρξη recordable history στον ναρκαλιευτή (ή σε αντίστοιχους κώδικες);

 

Ο bnvdarklord έφτιαξε ένα toy πρόγραμμα για την πάρτη του, για να μάθει 5 συγκεκριμένα πράγματα. Ζήτησε λίγο beta testing στο executable και είπε πως κάποια στιγμή ίσως ανεβάσει και τον κώδικα.

 

Τι git, τι history και τι πράσινα άλογα του λέτε του ανθρώπου;  Μήπως θέλετε να σας οργανώσει και σε team προκειμένου να διαβάσετε τον κώδικα του αν και όταν τον ανεβάσει; Ξέρω γω, μπορεί άμα δεν έχετε τη δυνατότητα ενδοσυνεννόησης με git ως beta testers team να μην μπορείτε να διαβάστε 10 αράδες κώδικα. Τί να πώ; Ούτε το Κυπριακό να ήτανε. Μπου τα ζιπ, μπου τα ideone, μπου τα code tags στο φόρουμ, μπου όλα εκτός από το git... εντάξει.

Δημοσ.

Νομίζω πως το συγκεριμένο έχει ήδη ανασκευασθεί...Δεν είναι και αυτό απλά μια άποψη, υπάρχει και η έννοια του history. Αν περιμένεις να μεγαλώσει, τότε έχεις χάσει αρκετή δουλειά απ' το history του project.

 

 

Υ.Γ

Δεν του είπε κανείς τι να κάνει.

Μια αγγλική παροιμία λέει "Μην προσπαθείς να μάθεις ένα γαϊδούρι αγγλικά. Και το χρόνο σου χάνεις και ενοχλείς και το γαϊδούρι". Ο migf1 δεν πρόκειται να κουνηθεί χιλιοστό από την θέση του ο κόσμος να γυρίσει ανάποδα. Θα παραθέσει links που σε κάποιο σημείο τους αχνο-αναφέρουν αυτό που θέλει να πει άσχετα αν στην πραγματικότητα το θέμα τους δεν έχει καμμία σχέση με αυτό που συζητείται και θα διαστρεβλώσει αυτά που λένε οι άλλοι όπως τον βολεύουν.

 

Παράδειγμα αποτελεί και αυτό που έγραψες. Ο OP ανέβασε ένα πρόγραμμα και ζήτησε γνώμες. Αν και δεν ζήτησε γνώμη για VCS, στο πλαίσιο της συζήτησης είναι απόλυτα θεμιτό να του πει κάποιος ότι η μεθοδολογία του δεν είναι δόκιμη και καλό θα είναι να χρησιμοποιήσει το Χ πράγμα. Εννοείται πως η τελική απόφαση αν θα ακολουθήσει την συμβουλή ή όχι είναι του bnvdarklord. Επίσης εννοείται πως ο migf1 δεν είναι χαζός και το γνωρίζει αυτό, με τι σκεπτικό δηλαδή γράψαμε αυτά που γράψαμε. Παρόλα αυτά, δεν έχει μάθει να διαφωνεί κανείς μαζί του και διαστρεβλώνει τα λεγόμενά μας και μας παρουσιάζει ότι θέλουμε να αναγκάσουμε τον OP να χρησιμοποιήσει git λες και παίρνουμε ποσοστά. Και μόνο εκείνο το χυδαίο μήνυμα στο οποίο τον προτρέπει να μην μας απολογείται να διαβάσεις, φτάνει για να καταλάβεις την τακτική του της διαστρέβλωσης.

 

Το νήμα έχει ξεφύγει πάρα πολύ οπότε δεν συμμετέχω άλλο στον εκτροχιασμό του. Το τελευταίο που θα πω είναι ότι κανείς δεν επιτέθηκε στον OP ή προσπάθησε να τον αναγκάσει να χρησιμοποιεί git άλλως θα θεωρηθεί παρακατιανός ή του ζήτησε να απολογηθεί που δεν το κάνει. Το μόνο που έγινε ήταν μια καλοπροαίρετη συμβουλή ότι το VCS (είτε git ή hg ή fossil ή whatever) θα τον βοηθήσει πάρα πολύ χωρίς να του εισάγει μεγάλο φόρτο. Τα υπόλοιπα είναι εγωισμοί και μικροπρέπειες του migf1.

  • Like 1
Δημοσ.

 

 

Μια αγγλική παροιμία λέει "Μην προσπαθείς να μάθεις ένα γαϊδούρι αγγλικά. Και το χρόνο σου χάνεις και ενοχλείς και το γαϊδούρι". Ο migf1 δεν πρόκειται να κουνηθεί χιλιοστό από την θέση του ο κόσμος να γυρίσει ανάποδα. Θα παραθέσει links που σε κάποιο σημείο τους αχνο-αναφέρουν αυτό που θέλει να πει άσχετα αν στην πραγματικότητα το θέμα τους δεν έχει καμμία σχέση με αυτό που συζητείται και θα διαστρεβλώσει αυτά που λένε οι άλλοι όπως τον βολεύουν.

 

Παράδειγμα αποτελεί και αυτό που έγραψες. Ο OP ανέβασε ένα πρόγραμμα και ζήτησε γνώμες. Αν και δεν ζήτησε γνώμη για VCS, στο πλαίσιο της συζήτησης είναι απόλυτα θεμιτό να του πει κάποιος ότι η μεθοδολογία του δεν είναι δόκιμη και καλό θα είναι να χρησιμοποιήσει το Χ πράγμα. Εννοείται πως η τελική απόφαση αν θα ακολουθήσει την συμβουλή ή όχι είναι του bnvdarklord. Επίσης εννοείται πως ο migf1 δεν είναι χαζός και το γνωρίζει αυτό, με τι σκεπτικό δηλαδή γράψαμε αυτά που γράψαμε. Παρόλα αυτά, δεν έχει μάθει να διαφωνεί κανείς μαζί του και διαστρεβλώνει τα λεγόμενά μας και μας παρουσιάζει ότι θέλουμε να αναγκάσουμε τον OP να χρησιμοποιήσει git λες και παίρνουμε ποσοστά. Και μόνο εκείνο το χυδαίο μήνυμα στο οποίο τον προτρέπει να μην μας απολογείται να διαβάσεις, φτάνει για να καταλάβεις την τακτική του της διαστρέβλωσης.

 

Το νήμα έχει ξεφύγει πάρα πολύ οπότε δεν συμμετέχω άλλο στον εκτροχιασμό του. Το τελευταίο που θα πω είναι ότι κανείς δεν επιτέθηκε στον OP ή προσπάθησε να τον αναγκάσει να χρησιμοποιεί git άλλως θα θεωρηθεί παρακατιανός ή του ζήτησε να απολογηθεί που δεν το κάνει. Το μόνο που έγινε ήταν μια καλοπροαίρετη συμβουλή ότι το VCS (είτε git ή hg ή fossil ή whatever) θα τον βοηθήσει πάρα πολύ χωρίς να του εισάγει μεγάλο φόρτο. Τα υπόλοιπα είναι εγωισμοί και μικροπρέπειες του migf1.

 

Δεν συμμετέχεις άλλο στο νήμα που εσύ εκτροχίασες θέλεις να πεις. Τα πάντα κυλούσαν όμορφα κι ωραία μέχρι που εμφανιστηκες εσύ, ο άμεμπτος, το μη γαιδούρι της παροιμίας, ο ευέλικτος, ο μη μκροπρεπής, ο άψογος συνομιλητής, και άρχισες να μας στολίζεις με εξυπνάδες και ειρωνίες. Κράτα τα να τα θυμάσαι (και τα από πάνω και τα από κατω) κύριε καθωσπρέπει, μη μικροπρεπή συνομιλητή, που "μου έκανες και την χάρη να κάνεις πως δεν διάβασες":

 

 

...

Και ο Δελαπόρτας δικός σας είναι. Zip το καλύτερο. Τι git και μ.κίες τώρα.

 

Παρεμπιπτόντως έχω ένα 386DX/40 με DOS, γνήσιο PKZIP της PKWare και γνήσια Turbo C. Μπορώ να σας το δώσω να κάνετε τη δουλειά σας. Το ανταλλάσσω με ένα 4πύρηνο i5 :)

 

Σου κάνω τη χάρη και κάνω πως δεν το διάβασα αυτό για τα VCS, ειδικά από κάποιον που προγραμματίζει χρόνια και ειδικά σε C που η εισαγωγή μιας απλής γραμμής κώδικα ή ενός δείκτη μπορεί πάρα πολύ εύκολα να οδηγήσει σε UB και να πηδήξει ολόκληρο το πρόγραμμα (και αυτό να γίνει αντιληπτό 8 μήνες μετά και αφού έχουν γίνει 4000 αλλαγές).

 

Στις παροιμίες είσαι πρώτος. Στις διαστρεβλώσεις και στα υπόλοιπα όμως ένα θεματάκι το έχεις.

 

 

Δημοσ.

Δεν ξέρω τι εννοείς με το "έχει ανασκευασθεί", ούτε ξέρω τι εννοεί ο defacer στην παράθεση που έχεις κάνει

 

Εμ, αν δεν ξέρεις και δεν ξέρεις γιατί εκφέρεις άποψη; Εδώ είναι το πρόβλημα. Φαίνεται πως δεν ξέρεις γιατί νομίζεις πως το history είναι κάτι βαρύγδουπο (αφού το βάζεις στην ίδια πρόταση με πράσινα άλογα, μάλλον και κάτι εξεζητημένο) και χρειάζεται μόνο πάνω από N γραμμές κώδικα. Το history απλά υπάρχει και φτιάχνετε μόνο του τσουκου τσουκου, δεν κοπιάζεις, δεν είναι κάτι διαπραγματεύσιμο, ξέρεις τι έκανες, ναι ακόμα και στις 10 γραμμές κώδικα που θα γίνουν 20.

 

if(loc_count > N) {
​   versioning_start();
}

Rinse and repeat. Whatever...

 

Ξέρω όμως πως μπορείς να ξεκινήσεις το version control όποτε θέλεις... Δεν χρειάζεται να το κάνεις από την αρχή. (wat??)

Όλοι το ξέρουν. Απλώς θα έχεις χάσει versions. Το όλο point του versioning.

 

Σχώρα με που μιλάω μόνο για το git, δεν έχει τύχει να δουλέψω κάποιο άλλο dvcs.

Δημοσ.

Σας λενε ας πούμε στην δουλεια που δεν υπάρχε κάποιο VCS ... Θέλουμε να φτιάξεις ένα προγραμματακι που να ειναι στο tray και να κάνει monitor ενα φακελο που θα το ρυθμίζεις για το αν ήρθε ενα αρχείο .Σε περιβάλλον windows και .net . Sorry θα κάτσετε να στησετε VCS για κάτι τέτοιο και δεν θα το ξεπεταξετε ας πούμε ;

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα
  • Δημιουργία νέου...