[git-users] Marking a branch "closed"?

2016-07-19 Thread Michael
Lets say I've got a topic branch. I've made a bunch of commits. It's messy. But it's done. As I understand it, best practice is to do a squash commit of the whole thing onto the parent branch (develop or master, depending on workflow). And I can do that. What do I do with the leftover? I thoug

[git-users] Seeing the blobs/files downloaded from a fetch / understanding a pull request

2016-07-19 Thread Michael
So I'm trying to make sure I'm seeing everything that I got in a fetch. My first attempt to fetch was: keybounceMBP:Finite-Fluids michael$ git fetch https://github.com/Draco18s/Finite-Fluids.git master remote: Counting objects: 12, done. remote: Compressing objects: 100% (4/4), done. remote: Tot

Re: [git-users] Marking a branch "closed"?

2016-07-19 Thread Gergely Polonkai
Hello, that, again, depends on your workflow. For one project, I interactive-rebase my feature branches often, and merge them into master when they are finished; after that, they can live forever in the repo, and if the feature needs a fix or change, I can check them out. For another project, I sq

Re: [git-users] Marking a branch "closed"?

2016-07-19 Thread Charles Manning
Squashing makes sense if you have a really ratty bunch of checkins with work-in-progress checkins etc., but unless it's a trivial topic branch I would still typically make the final set of commits into a few logical steps. It costs pretty much nothing to leave old topic branches around (but a few

Re: [git-users] Marking a branch "closed"?

2016-07-19 Thread Michael
On 2016-07-19, at 11:02 PM, Charles Manning wrote: > Squashing makes sense if you have a really ratty bunch of checkins with > work-in-progress checkins etc., but unless it's a trivial topic branch I > would still typically make the final set of commits into a few logical steps. > > It costs