What do I do, when I don’t understand the vagaries of tech?
Why? I ask my friends to drum some sense into me.
As I write more code, I wanted to get some sense of the cultural norms about how to use git.
So I asked my young friends, Nabarun and Sayan all sorts of dumbass questions.
Here it is, warts and all for posterity (but lightly edited).
If you’d love to come teach me or be part of the conversation, head on over to the IRC #learnandteach channel on the freenode server.
jasonbraganza: nabarun, sayan - as i keep practicing writing code more, i find myself doing a daily git branch off the previous days branch because I want each day’s progress. is this normal practice? or ok behaviour? XD
sayan: Nope! rather than branch you can have daily commits
nabarun: same thoughts ^^^
nabarun: have commits as your checkpoints instead of branches
jasonbraganza: ok. :)
nabarun: and then everyday or any day in future you can look at commit diffs
sayan: exactly
sayan: you can branch off to create a backup of the commits, if you want to
jasonbraganza: what if i have too many commits?
sayan: but before sending that work to any open source projects, squash or rearrange them
jasonbraganza: ok i should learn that too.
jasonbraganza: thank you both :)
jasonbraganza: if anymore advice, i’m still all ears.
sayan: When you are working on a big work, and you send of to review it is beneficial to arrange the commits in a way that reviewers can go through the commits
sayan: and the whole history feels like a story
jasonbraganza: i don’t understand. are you telling me it is possible to arrange commits in a manner other than chronological?
jasonbraganza: or if you pointed me someplace you like the story, maybe i’ll understand better.
sayan: I’m looking for a PR in fedora repo, I will see if I find but there is a smaller one that I did
jasonbraganza: thank you.
sayan: https://github.com/coreos/mantle/pull/934/commits
sayan: There are only 3 commits here, but first commit adds the provision to add new systems, then add dependency that the new system I will add will need, and then add the new system
sayan: jasonbraganza: found the PR: https://pagure.io/fedora-hubs/pull-request/323
sayan: this commit had 45 commits, if you had idea of the project then when you read the commits in order, old to new, it would make sense how the PR evolves
sayan: There is this comment as well in description
sayan: I recognize that it’s a big change, so I’d like to add the following :
sayan: try to read commits in order, I’ve made them topic-specific, so you can understand what’s being changed and why. Reading the whole “Files changed” page is actually much harder.
jasonbraganza: now i understand.
jasonbraganza: i think it boils down to a difference in how i think about git
sayan: This you cannot do when you code, this is often done later, or at intervals when you keep arranging the commits
jasonbraganza: that is what i was getting to ^
jasonbraganza: when i code, i want to do it iteratively
sayan: When I work if it’s a big work, I just keep creating “Tmp commits”
jasonbraganza: and that probably could mean me jumping up and down all over the place.
sayan: “Tmp commits is actually the commit message :)
jasonbraganza: and since i am paranoid, i keep committing my work
sayan: jasonbraganza: doing regular commits is always good
jasonbraganza: so if i understand it right, you say that i can then change the order of my commits when i push to someplace remote, in a way that it all makes sense?
sayan: jasonbraganza: see this https://github.com/kinvolk/coreos-overlay/commit/7fb8a7258c4dbd61d512c831272b3ebb36cf2e45
jasonbraganza: ^ that resembles more of my workflow :)
sayan: jasonbraganza: you can push whatever you want to the remote, but when you create the pull request at the end of the day it should make sense to the reviewers
jasonbraganza: aha. so that is the missing piece.
sayan: A pull request can be after say 1 week or 2 months, but commits you can do hourly, daily etc
jasonbraganza: will ask you to help, whenever i do this next time.
jasonbraganza: thank you sayan :)
sayan: jasonbraganza: sure
sayan: jasonbraganza: another idea, sometimes you might find yourself writing 1000 lines of code in an hour, and sometimes 5 lines in an hour
jasonbraganza: and obviously since I write, I am obviously a big fan of someone leading me to a conclusion in a logical flow ergo i am heavily in favour of writing stories in code as well
jasonbraganza: sayan, hmm true. go on
sayan: in the former case you should commit every 2-3 minutes, and in the later case you can do a daily commit. People say to regularly commit because it’s hard to lose things when it is committed in git
jasonbraganza: ok. that makes sense. thank you :)
sayan: np :)
jasonbraganza: as for committing regularly, i am always scared of having to redo my work or losing it. so that is something i do religiously :)
sayan: jasonbraganza: same here, and probably same for all
sayan: once I wrote a 100 lines of code over 2-3 days, lost because I did not commit
sayan: I was happy to get the code from stash
sayan: From that day, I just keep creating tmp commits
jasonbraganza: question, only files that are added are in stash, correct? if i create a new file, that won’t be there?
sayan: jasonbraganza: yes, new files won’t be there.
sayan: I was lucky, that I do stash apply and not stash pop
jasonbraganza: thank you sayan. my mental model of git grows clearer by the day :)
jasonbraganza: apply if i intuit correctly, will pull everything from stash, whereas pop will get me the newest one?
jasonbraganza: sayan, nabarun also, do i have y’alls permission to put this conversation on the blog? might help some other newbie?
sayan: jasonbraganza: kushal has been asking me to write a git book for years atleast 5-6 years
sayan: jasonbraganza: apply stash n: will apply the patch but also keep a copy in the stash list
jasonbraganza: maybe i should pull it out of you by asking questions like these XD
sayan: jasonbraganza: pop will pop the last and also remove from stash list
sayan: last = newest one, as you said
jasonbraganza: where n is any random number in the stash?
sayan: yes, in stash list
jasonbraganza: understood :)
nabarun: nabarun: sure. although I have not contributed much here. :)
nabarun: jasonbraganza: ^^^
sayan: every time you do git stash, it puts it in stash. git stash list will give you all in stash
jasonbraganza: nabarun, consent matters :)
nabarun: jasonbraganza: it does!
nabarun: git stash pop == git stash apply 0 && git stash drop 0
sayan: ^^ +1
jasonbraganza: why would you do a git stash as opposed to a git commit?
nabarun: jasonbraganza: for cases where we want to stash our work aside to work on something else in the working space.
sayan: jasonbraganza: not yet prepared like a commit, or moving around branches
sayan: jasonbraganza: but you can do a tmp commit as well
sayan: jasonbraganza: stash is quicker when you want to move around branches
nabarun: jasonbraganza: IRL example, I am working on lubing my keyboard switches but realize that it’s work time. So, stash that aside and start working on my work stuff. When my work gets over, I can pop things off my stash of unfinished work.
sayan: also suppose you want to rebase, and have changes. If you don’t have autostash then you have to stash manually :)
jasonbraganza: nabarun, that analogy does not quite fit in my head. i am just moving to a completely new space no, when i have to work
sayan: s/rebase/pull changes/
nabarun: jasonbraganza: think of it as you have just one workspace.
jasonbraganza: aah, now i get it better :)
sayan: nabarun: here wants to say you have one table for all technical things for example.
nabarun: jasonbraganza: for example, I won’t keep copies of the same git workspace for different workstreams.
jasonbraganza: nabarun, sayan thank you
nabarun: jasonbraganza: jasonbraganza: more technical example, https://share.riseup.net/#NN3bvnSif2gn5JC2i0GkgQ I work on the same copy of kubernetes codebase for anything I am doing but stash and unstash things as I switch contexts.
nabarun: jasonbraganza: I don’t keep more than one copy of the kubernetes codebase.
sayan: jasonbraganza: my office team right now is spread toooooo thin. hope things change in future
jasonbraganza: nabarun, my headspace says to use branches everytime. i need to understand stashes better
nabarun: jasonbraganza: okay.
jasonbraganza: nabarun, so you just stash things and stash things and stash things and then keep switching between them (for a single project?)
nabarun: jasonbraganza: my mental model of differentiating them is like branches are completed pieces of work. stashes are incomplete state of my mind.
jasonbraganza: nabarun, feels better like you describe.
jasonbraganza: i should learn to do this.
nabarun: jasonbraganza: I do both branches as well as stashes based on what my mind thinks of the situation.
jasonbraganza: yea i’m sure, i’ll evolve to something like that mindset
nabarun: yup. it will come with practice.
sayan: my mental model is a bit simpler, create branch when you work on something new, and commits as necessary, stash if you think you need to work on some other branch for the time being
jasonbraganza: sayan, what about saving daily/regular progress? i like having snapshots of progress. how do you tackle that?
sayan: jasonbraganza: https://github.com/sayanchowdhury/words.yudocaa.in/commits/master
sayan: this is the only place I do regular commits/daily progress
jasonbraganza: ok
sayan: other than this, I do commits as required.
jasonbraganza: understood :)
nabarun: saving == committing at the desired interval. :)
jasonbraganza: nabarun, this is me :)
nabarun: jasonbraganza: as in?
jasonbraganza: saving == committing at the desired interval.
nabarun: haha. that is me too.
nabarun: my working branches are filled with “fixup! foo bar” commits.
sayan: nabarun: okay I would not mention that to jasonbraganza today
sayan: fixup commits are bit advanced
sayan: :)
nabarun: sayan: sorry!
sayan: nabarun: no need to be sorry, just putting my thoughts
sayan: when you have to arrange the commits, fixup commits are best IMO
nabarun: figuratively speaking they are just some extra metadata. nothing special behind them.
sayan: nabarun: if that for rebase?
nabarun: eh?
jasonbraganza: nabarun, metadata for whom? git? or github?
nabarun: jasonbraganza: git.
jasonbraganza: aah. nice :)
sayan: Interesting, if I do autosquash will those “fixup!” work?
sayan: nabarun: ^^
sayan: git rebase –autosquash
nabarun: yes. it should.
jasonbraganza: and the best part about asking both of you, is realising that ok, the funny/advanced parts of a workflow might differ from person to person, but the basics stay the same, relatively.
sayan: I earlier thought you were talking about git commit –fixup, but you were saying git commit -m “fixup! … "
sayan: nabarun: ^^
jasonbraganza: kushal, hurrah!
nabarun: sayan: both of what you specified are valid ways of working.
nabarun: sayan: git-rebase just looks at the commit message and decides the course of action.
nabarun: jasonbraganza: yessss! git is simple yet complex. xD
sayan: jasonbraganza: nabarun gulped git book :)
nabarun: NO!
nabarun: I didn’t read a complete chapter of that book.
jasonbraganza: nabarun, that was me. i still always have it open :) it teaches me the ‘how’. the why and the culture is why i come to you folk :)
sayan: nabarun: but you read :)
sayan: I just learnt by seeing :)
sayan: I should read though, interpreted knowledge is not always good
nabarun: sayan: I learnt by practising and a lot of man git-subcommand:
nabarun: jasonbraganza: nice nice.
sayan: jasonbraganza: it’s a very good book
sayan: nabarun: nice!
jasonbraganza: extremely good book. very lucid
P.S. Subscribe to my mailing list!
Forward these posts and letters to your friends and get them to subscribe!
P.P.S. Feed my insatiable reading habit.