Cleaner local git workflow... suggestions?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Cleaner local git workflow... suggestions?

jamshark70-2
Hi all,

I would like some suggestions on how to manage a git environment with minimum fuss.

Today's situation: After updating a few things in my 3.9 branch, I went to do some work, and found a problem that I had encountered before and patched locally (namely, that if you're using a dark screen theme, the background color for unselected document tabs is exactly the same as the text color, making the tabs useless). So I thought, OK, I'll take a couple of minutes, patch it properly, turn it into a PR, and get back to business.

A few incidents of git confusion (files getting pulled into the commit that I had explicitly not selected to be committed, etc.) and 15-20 minutes later, I'm now rebuilding the "develop" branch from scratch (20 minutes) to make absolutely sure it's okay before PR-ing.

That is, it's something like 45 minutes to check in **a two-line fix**.

Frankly, it makes me want to go back to patch files on the mailing list. I have things I want to contribute, but if the PR mechanics are so onerous, I'm not sure it's the best use of my time.

I must be doing something wrong... How do you folks do it?

Thanks,
hjh


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

jamshark70-2
---- On Thu, 04 Jan 2018 17:41:21 +0800 <[hidden email]> wrote ----
> I would like some suggestions on how to manage a git environment with minimum fuss.

I went to "git push --force" the corrected branch (after I had successfully pushed the branch before) and -- as if on cue -- git complained:


dlm@xiaogou:~/share/sc-hjh.git$ git push --force topic/doc-tab-color
warning: push.default is unset; its implicit value has changed in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the traditional behavior, use:

  git config --global push.default matching
.... yadda yadda yadda


See, the thing is, I don't care, and I don't think I should have to care about this in order to contribute to SuperCollider.

Sorry, but I'm fed up with this. There has got to be a better way.

Two lines. I want to check in two lines, and it's an hour later. I'm done.

hjh


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

jamshark70-2
---- On Thu, 04 Jan 2018 17:52:22 +0800 <[hidden email]> wrote ----
> I went to "git push --force" the corrected branch (after I had successfully pushed the branch before) and -- as if on cue -- git complained:

Sorry for noise, that was my mistake.

But it does underscore the point... whatever I'm doing with git is not helping. So, I'm asking for advice on how to clean it up so that maybe I could do a simple PR without so much nonsense.

hjh


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

brianlheim
Hey James,

I'm not sure exactly what you're doing, so I can't give you detailed suggestions on alternatives for your workflow. Here is how I typically work when I submit a PR:

1 stash, commit, obliterate existing changes if I need to switch branches
2 check out the correct branch I want to work from (this is 3.9 or dev lately)
3 create a new branch
4 make the changes, potentially rebuilding to test
5 stage the changes using interactive patch
6 commit
7 push
8 repeat 4-7 as necessary. I may repeat 5-6 multiple times if I want to separate my changes into logical commits

In git, that looks like this:

1 git status; git stash or git reset --hard 
2 git checkout develop 
3 git checkout -b issue/3266 
4 ...
5 git add -p 
6 git commit -m "Message"
7 git push -u origin issue/3266

With my aliases, I streamlined this process:

1 gs; gR (hard reset, I barely ever stash speculative stuff)
2 gh develop
3 gH issue/3266
4 ...
5 ga 
6 gc "message" 
7 gP (gp is normal push, gP creates a remote tracking branch on origin)

From what you're describing, it sounds like interactive patching (git add -p), which lets you stage exactly what you want, and also gives you a chance to review your changes, would be of the most help. I never add using any other method, I've been bitten too many times by accidentally committing stray files or whitespace changes or debugging code.

It also sounds like gP or some variant of it would be a good alias to have. I can never quite remember the syntax for establishing tracking branches, and in my mind it varies slightly between checkout/branch and pushing.

If you find yourself reapplying the same patches frequently, you should create an actual patch you can apply instead of manually making the changes again. I believe git diff and git patch are commands for that but it's been awhile since I did that.

If you could share your reflog (git reflog) that might also help in figuring out what the issue might have been. As an aside, using the reflog with git reset is sometimes a very easy way to get out of a sticky situation.

-Brian

On Jan 4, 2018 4:56 AM, <[hidden email]> wrote:
---- On Thu, 04 Jan 2018 17:52:22 +0800 <[hidden email]> wrote ----
> I went to "git push --force" the corrected branch (after I had successfully pushed the branch before) and -- as if on cue -- git complained:

Sorry for noise, that was my mistake.

But it does underscore the point... whatever I'm doing with git is not helping. So, I'm asking for advice on how to clean it up so that maybe I could do a simple PR without so much nonsense.

hjh


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

jamshark70-2

On January 4, 2018 10:45:37 PM [hidden email] wrote:

> Hey James,
>
> I'm not sure exactly what you're doing, so I can't give you detailed
> suggestions on alternatives for your workflow. Here is how I typically work
> when I submit a PR:
>
> 1 stash, commit, obliterate existing changes if I need to switch branches

Thanks for listening. I think here is where I run into the most trouble.

For some years, I haven't been able to run on a totally clean branch matching an upstream branch. After the last PR went out of control, I thought, OK, I'll reclone, start over with less local noise in my repository. (Cloning, btw, took *two hours* -- often we assume git operations are fast, but in other parts of the world, maybe not.) Rebuilt, no problem... but then I still had the unhelpful document tab colors. So, just to use the IDE *at all*, I currently have no choice but to run off of a separate, patched branch.

Scott Carver once used the phrase "technical debt"... so let me say that again: I can't use 3.9 out of the box.

Experience tells me, next time I want to make a PR, I will think "this shouldn't be too hard," but git WILL throw some surprise at me. Last night, it was that some other unrelated changes got pulled into my one commit, even though I had started with "git add [the one specific file]" and "git commit -m ..." and I didn't find git's over-enthusiasm until I was checking the PR at github.

I think it would work better for me if I could a/ stay on a clean branch most of the time (currently not possible) and b/ never ever have more than one open set of changes at a time (nice plan, but life doesn't work that way). A, I don't have a lot of control over. B, I could influence by cutting back on dev activities -- "hm, interesting problem, but I don't have room for it." I don't really want that and I don't think the SC community should be happy with members stepping back just because the toolchain is a pain in the ***.


> 2 check out the correct branch I want to work from (this is 3.9 or dev
> lately)
> 3 create a new branch
> 4 make the changes, potentially rebuilding to test
> 5 stage the changes using interactive patch
> 6 commit
> 7 push
> 8 repeat 4-7 as necessary. I may repeat 5-6 multiple times if I want to
> separate my changes into logical commits


"separate my changes into logical commits" -- in practice, this is a nightmare. It's never as easy as it sounds.


> From what you're describing, it sounds like interactive patching (git add
> -p), which lets you stage exactly what you want, and also gives you a
> chance to review your changes, would be of the most help.

I already use qgit for this. It helps with the simple cases but I still have problems. (Btw I'm still looking for a git gui that doesn't s---, erm, have some major deficiency. Qgit has a very nice commit-staging interface can't do an initial commit or manage branches. Git-cola's commit interface is bloody awful. Lately I heard of GitForce, haven't tried it yet.)

I'm coming to the conclusion that git assumes a high degree of cleanliness in one's working method, which is the opposite of a creative flow. I just don't want to deal with that friction so much anymore. Git isn't going away (and there may not be a better alternative -- all SCM systems need some precision), so maybe I just have to be more careful about what I do and don't take on. Fortunately 3.9 is a lot better than 3.8 so I shouldn't need as many local patches.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com

Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

brianlheim
> So, just to use the IDE *at all*, I currently have no choice but to run off of a separate, patched branch.

How many patches are we talking? You have only mentioned the IDE tab colors, is that it? Or is there other stuff you could open a PR for?

One alternative, that would keep you on the plain dev branch but would add a little complexity locally, would be to save your patches as actual patch files, apply them to the codebase before building, then unapply them (git apply -R) after building. If you worked it into a single build command, it would be seamless. But, that's assuming these are changes that you don't expect to be merged for a long time (or possibly never).

> Experience tells me, next time I want to make a PR, I will think "this shouldn't be too hard," but git WILL throw some surprise at me. Last night, it was that some other unrelated changes got pulled into my one commit, even though I had started with "git add [the one specific file]" and "git commit -m ..." and I didn't find git's over-enthusiasm until I was checking the PR at github.

Sounds like this would have been a case where always using interactive patch would be helpful, no?


"separate my changes into logical commits" -- in practice, this is a nightmare. It's never as easy as it sounds.

Sorry, but I totally disagree. I have learned how to do this more and more effectively over the last year. It's certainly not impossible with a little forethought. If you are having trouble with this aspect of development, it might mean you should be more careful in your workflow. Take notes, design things out on paper before coding, or even plan out how the commits will look in your head or on paper before you do them. I've done the last one a lot - before I start working on a change, I list out all the little bits that I know will need to be checked or go into it. Sometimes I do that more than once while working on a branch; several times with the lockClientIDWhileRunning PR that went in recently. It sounds like extra work at first but after time it becomes second nature (at least, it did for me).

> I'm coming to the conclusion that git assumes a high degree of cleanliness in one's working method, which is the opposite of a creative flow.

I usually work in small cycles of exploration and cleanup + commit. For me it's not about cleanliness so much as discipline, which is a complement rather than a foil to creativity. Just something to think about.
 

James, while working on this project I have seen you complain many times about all the time you've wasted struggling with git. My honest opinion is that if you spent a couple hours learning more about git and how to use it effectively, and/or practicing with a dummy project (I've done this), _in the terminal_, it would save you a lot of time. GUIs are just not the way to go IMO; they obscure how git actually works, provide limited functionality, provide very little aid when it comes to fixing problems, and make development much less enjoyable and flow-like because of all the context switching and clicking. I took the plunge (from SourceTree to CLI) about a year ago. It's much more beneficial in the long run, and since we seem to be talking about the long run here, this is the really the only thing I can think to say. I would be happy to recommend some articles or talks that have helped me.

-Brian

Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

yvan.sc
hi James.

> Last night, it was that some other unrelated changes got pulled into my
> one commit, even though I had started with "git add [the one specific
> file]" and "git commit -m ..." and I didn't find git's over-enthusiasm
> until I was checking the PR at github

You might want to make sure you're only committing the files that
contain changes:

$ git add foo bar
$ git ci foo bar -m "..."

> git push --force topic/doc-tab-color
> warning: push.default is unset;

yeah if you do not specify where to push git cannot know either :)

// I always use `origin` for the main repo, some people use `upstream`, ..
$ git push -f origin topic/doc-tab-color


I agree with Brian that with a little bit more of git knowledge it
should be totally pain-free :)

A side note about your original question though: staying up-to-date and
submitting PRs with a local patch is a PITA and honestly I don't think
there's any easy way to solve this kind of situation.


cheers,
y

--
http://s3pt3ntrion.com
http://www.facebook.com/pages/Septentrion/357546467715618
http://soundcloud.com/yvanvolochine
http://soundcloud.com/elgusanorojo
http://vimeo.com/yv

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

jamshark70-2
> You might want to make sure you're only committing the files that
> contain changes:
>
> $ git add foo bar
> $ git ci foo bar -m "..."

**That's what I started with.** Then I realized I was on a 3.9 branch, not develop, and I needed to switch over, and somewhere during switching over, it brought other changes in. I'm not sure exactly what happened.

I know "git add" and I never ever "git commit -a"... EVER.

> yeah if you do not specify where to push git cannot know either :)

Touching on one of my issues with git:

GIt-speak: "warning: push.default is unset;"
Human-speak: "Your command arguments are incorrect: should be 'git push remote branch'."
Me to git: "Well, why didn't you say so?"

User-friendly? Sclang parser error messages are easier to interpret.

> I agree with Brian that with a little bit more of git knowledge it
> should be totally pain-free :)
>
> A side note about your original question though: staying up-to-date and
> submitting PRs with a local patch is a PITA and honestly I don't think
> there's any easy way to solve this kind of situation.

This made me chuckle a bit because... it "should" be easy, but there isn't any easy way... that's precisely my experience.

Venting aside...

Sincere thanks to Brian for genuine patience with a series of messages from me that aren't exactly professionally appropriate. That's very helpful to me and I appreciate it.

> If you are having trouble with this aspect of development, it might mean you should be more careful in your workflow. Take notes, design things out on paper before coding, or even plan out how the commits will look in your head or on paper before you do them.

I've been thinking about the problem all day. This gets pretty much to the core of it.

I think, in the short term, part of the answer *is* for me to back off. One area where I get in trouble is, for instance, having a branch open for Rest reworking *and* a branch for initial-trigger behavior *and* a couple of other things *and* local patches. It's too much. I think I had better promise myself that I will stick to *one* open issue at a time. Brian, admiration and respect that you've taught yourself how to handle large numbers of open issues... but I don't think I can make that as much of a priority for myself, at least not right now. (If "discipline is a complement rather than a foil to creativity" -- and I do see your point -- the appropriate discipline for me may be simply to avoid over-involving myself.)

> How many patches are we talking? You have only mentioned the IDE tab colors, is that it? Or is there other stuff you could open a PR for?

At present, as far as I know, the tab colors are the only critical thing. With 3.8, I had about half a dozen local patches that I couldn't live without. Most of those, I did eventually submit as PRs and they did get merged in. (I think there are a couple of supernova tweaks that I didn't do.) I expect 3.9 will be easier to get along with... that's possibly why I overreacted yesterday (expecting things to be easier, when they turned out not to be).

> I would be happy to recommend some articles or talks that have helped me.

Thanks, that would be helpful.

hjh


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

yvan.sc
> **That's what I started with.** Then I realized I was on a 3.9 branch, not develop, and I needed to switch over, and somewhere during switching over, it brought other changes in. I'm not sure exactly what happened

JIC it might help, here's what I do in such a situation:

// Commit things and realize you're on the wrong branch
// Identify commits you want to move on another branch
// They should be the last ones if you've been careful =)
$ git log
// Say you want to keep the last 5 commits
$ git format-patch -5
// Go back to proper branch
$ git checkout BRANCH
// Make sure you're up-to-date (I use `origin` but MMV)
$ git pull origin BRANCH
// Add your commits again
$ git am 000*
// **Or** apply them one by one
$ git am 0001-...

As I said before, having to maintain a local patch can be super tricky
if you're not well organized.

[OT] What is the Qt style/theme you're using in UbuntuStudio? I'd like
to replicate this bug locally and have a closer look.. Not being able to
see filenames in tabs should be fixed asap IMHO..

cheers,
y

--
http://s3pt3ntrion.com
http://www.facebook.com/pages/Septentrion/357546467715618
http://soundcloud.com/yvanvolochine
http://soundcloud.com/elgusanorojo
http://vimeo.com/yv

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

Scott Carver
So, I've settled on something like this for my local git workflow (at least, when I'm NOT doing specific larger feature development on an isolated branch):

1. I stay in one of several personal development branches locally.
2. When I make small spot-changes to code (e.g. tab colors), I don't check them in immediately.
2. When I'm in an organizational mood / have some time, I walk through the changes I've accumulated. I gather related changes, and then:
     2.1. Create a branch directly off of origin/master (or 3.9, something relatively canonical), named e.g. topic/ide-tab-color, and switch to it.
     2.2. Commit my change(s) to that branch
     2.3. Switch back to where i was before, and immediately merge the branch I just created
3. In a text file, I keep a list of my own spot-fix / small change branches. If I ever need to get back to a clean-ish state, I just pull a new branch from origin/master, and then merge everything from the list. I'm considering labelling my branches e.g. "scztt/topic/ide-tab-color" so I can just track my own personal branches that way. You could keep a text file of actual "git merge ..." commands, so all you need to do to recreate the branch is copy-paste them into the terminal.
4. If I screw up and commit a change somewhere that it doesn't belong (e.g. a sandbox-y develop branch), I'll do step #2 above, but cherry pick the changes in order.

The gist is, basically: if you're going to have local sandbox-y develop branches, NEVER commit to them directly - always commit to a branch that's semantically meaningful (one that describes how it differs from master / some other parent). Semantically, a branch is just a tag with a name that describes how branch B is different from parent A. This implies first that you have a coherent parent A (the thing you might eventually merge into, the thing your branch differs FROM) - and second, that there is some coherent, well-defined difference between them. If you ever have a branch that doesn't fit these two properties, stop immediately and try to separate changes out into coherent branches by cherry picking / merging. Clearly, a personal branch ala "my-dev-branch" don't describe any coherent difference - any changes you add directly to a branch like that are books stuffed in a box in your attic: they still /exist/, but you definitely can't find them without a significant amount of work.

- Scott Carver

On Fri, Jan 5, 2018 at 8:09 AM <[hidden email]> wrote:
> **That's what I started with.** Then I realized I was on a 3.9 branch, not develop, and I needed to switch over, and somewhere during switching over, it brought other changes in. I'm not sure exactly what happened

JIC it might help, here's what I do in such a situation:

// Commit things and realize you're on the wrong branch
// Identify commits you want to move on another branch
// They should be the last ones if you've been careful =)
$ git log
// Say you want to keep the last 5 commits
$ git format-patch -5
// Go back to proper branch
$ git checkout BRANCH
// Make sure you're up-to-date (I use `origin` but MMV)
$ git pull origin BRANCH
// Add your commits again
$ git am 000*
// **Or** apply them one by one
$ git am 0001-...

As I said before, having to maintain a local patch can be super tricky
if you're not well organized.

[OT] What is the Qt style/theme you're using in UbuntuStudio? I'd like
to replicate this bug locally and have a closer look.. Not being able to
see filenames in tabs should be fixed asap IMHO..

cheers,
y

--
http://s3pt3ntrion.com
http://www.facebook.com/pages/Septentrion/357546467715618
http://soundcloud.com/yvanvolochine
http://soundcloud.com/elgusanorojo
http://vimeo.com/yv

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

brianlheim
> Sincere thanks to Brian for genuine patience with a series of messages from me that aren't exactly professionally appropriate. That's very helpful to me and I appreciate it.

You're more than welcome! I'm glad it helps.

>
At present, as far as I know, the tab colors are the only critical thing.

>
This made me chuckle a bit because... it "should" be easy, but there isn't any easy way... that's precisely my experience.

There are some tools out there that assist with performing Github-specific actions from the command line. If you give it a access token that has limited privileges, you should be able to test it out without completely blowing things up. I've never tried them before, but they seem promising and I've been considering it as an alternative to "open up the browser, navigate to whatever page, click the pull request button, blah blah blah" as the final steps of my PR submission process.

Here's one that I found: https://hub.github.com/. There are some others out there, I might give them a try soon. If I find something I like I'll post a note to the list.

> > I would be happy to recommend some articles or talks that have helped me.

> Thanks, that would be helpful.

Nathan had an intermediate-level article that I read once that was AMAZING, but I can't find it again. This is before I started taking notes on such things. :/

Git Everyday (https://www.kernel.org/pub/software/scm/git/docs/giteveryday.html)
- some quick commands for people working on projects of various scales

Knowledge is Power: Understanding Git (https://www.youtube.com/watch?v=sevc6668cQ0)
47 min, intermediate-advanced level understanding
git internals
"understanding from first principles" (understand what commands must exist)
"be able to implement commands yourself"

Git From the Bits Up (https://www.youtube.com/watch?v=MYP56QJpDr4)
1 hr, internals, moderately advanced

summary:
• `git <cmd> -- <filename>` - only apply this command to this file (checkout, log, diff, etc.)
• how to make a commit without using git commit or git add
• how to use reflog
• how to use rebase
• how to use interactive rebase

-Brian

On Fri, Jan 5, 2018 at 3:16 PM, <[hidden email]> wrote:
So, I've settled on something like this for my local git workflow (at least, when I'm NOT doing specific larger feature development on an isolated branch):

1. I stay in one of several personal development branches locally.
2. When I make small spot-changes to code (e.g. tab colors), I don't check them in immediately.
2. When I'm in an organizational mood / have some time, I walk through the changes I've accumulated. I gather related changes, and then:
     2.1. Create a branch directly off of origin/master (or 3.9, something relatively canonical), named e.g. topic/ide-tab-color, and switch to it.
     2.2. Commit my change(s) to that branch
     2.3. Switch back to where i was before, and immediately merge the branch I just created
3. In a text file, I keep a list of my own spot-fix / small change branches. If I ever need to get back to a clean-ish state, I just pull a new branch from origin/master, and then merge everything from the list. I'm considering labelling my branches e.g. "scztt/topic/ide-tab-color" so I can just track my own personal branches that way. You could keep a text file of actual "git merge ..." commands, so all you need to do to recreate the branch is copy-paste them into the terminal.
4. If I screw up and commit a change somewhere that it doesn't belong (e.g. a sandbox-y develop branch), I'll do step #2 above, but cherry pick the changes in order.

The gist is, basically: if you're going to have local sandbox-y develop branches, NEVER commit to them directly - always commit to a branch that's semantically meaningful (one that describes how it differs from master / some other parent). Semantically, a branch is just a tag with a name that describes how branch B is different from parent A. This implies first that you have a coherent parent A (the thing you might eventually merge into, the thing your branch differs FROM) - and second, that there is some coherent, well-defined difference between them. If you ever have a branch that doesn't fit these two properties, stop immediately and try to separate changes out into coherent branches by cherry picking / merging. Clearly, a personal branch ala "my-dev-branch" don't describe any coherent difference - any changes you add directly to a branch like that are books stuffed in a box in your attic: they still /exist/, but you definitely can't find them without a significant amount of work.

- Scott Carver

On Fri, Jan 5, 2018 at 8:09 AM <[hidden email]> wrote:
> **That's what I started with.** Then I realized I was on a 3.9 branch, not develop, and I needed to switch over, and somewhere during switching over, it brought other changes in. I'm not sure exactly what happened

JIC it might help, here's what I do in such a situation:

// Commit things and realize you're on the wrong branch
// Identify commits you want to move on another branch
// They should be the last ones if you've been careful =)
$ git log
// Say you want to keep the last 5 commits
$ git format-patch -5
// Go back to proper branch
$ git checkout BRANCH
// Make sure you're up-to-date (I use `origin` but MMV)
$ git pull origin BRANCH
// Add your commits again
$ git am 000*
// **Or** apply them one by one
$ git am 0001-...

As I said before, having to maintain a local patch can be super tricky
if you're not well organized.

[OT] What is the Qt style/theme you're using in UbuntuStudio? I'd like
to replicate this bug locally and have a closer look.. Not being able to
see filenames in tabs should be fixed asap IMHO..

cheers,
y

--
http://s3pt3ntrion.com
http://www.facebook.com/pages/Septentrion/357546467715618
http://soundcloud.com/yvanvolochine
http://soundcloud.com/elgusanorojo
http://vimeo.com/yv

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

Nathan Ho
On 2018-01-05 13:44, [hidden email] wrote:
> Nathan had an intermediate-level article that I read once that was
> AMAZING, but I can't find it again. This is before I started taking
> notes on such things. :/

this one?

https://eev.ee/blog/2015/04/24/just-enough-git-to-be-less-dangerous/

also, if we're sharing git tips, i recommend installing this instead of
typing "git status" over and over again:

https://github.com/magicmonty/bash-git-prompt


nathan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

brianlheim
Yes, thank you! That would be my recommendation for what to read first, the two talks I shared are more on the advanced side.

On Jan 5, 2018 5:06 PM, <[hidden email]> wrote:
On 2018-01-05 13:44, [hidden email] wrote:
Nathan had an intermediate-level article that I read once that was
AMAZING, but I can't find it again. This is before I started taking
notes on such things. :/

this one?

https://eev.ee/blog/2015/04/24/just-enough-git-to-be-less-dangerous/

also, if we're sharing git tips, i recommend installing this instead of typing "git status" over and over again:

https://github.com/magicmonty/bash-git-prompt


nathan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

jamshark70-2
In reply to this post by Scott Carver
Thanks again for the suggestions. Looking forward to reading the article Nathan found.

Brian:
> There are some tools out there that assist with performing Github-specific actions from the command line. If you give it a access token that has limited privileges, you should be able to test it out without completely blowing things up.

Hm, for myself, I'm reasonably comfortable with the basics at the commandline (though, as noted the other day, occasionally I drop an argument and get confused).

Specifically, what I'm missing in a GUI is easy browsing of branches to get rid of dead weight. That's another area where I get in trouble -- stale branches stay around, and then I get lost. Qgit lets you view any branch, but the key/mouse sequence is not convenient. I would like to have a list of branches at the side, click on one, see the top of that branch's log, and then be able to delete old branches from the list.

Qgit's commit interface *does* let you preview the diff, and for every commit problem I've complained about, this interface has saved me from hundreds, maybe thousands, of mistakes. I think I'm in good shape there.

Scott C.:
> The gist is, basically: if you're going to have local sandbox-y develop branches, NEVER commit to them directly - always commit to a branch that's semantically meaningful (one that describes how it differs from master / some other parent).

O. M. G.

OK, yeah, that may be a key idea that I missed. I already refuse to commit directly to any branch that's tracking origin or upstream (always topic branch -> push to origin -> PR -> somebody merges it upstream -> fetch upstream -> merge locally)... I didn't think of applying that logic to sandbox branches. Sure. Makes perfect sense, and I can see how that would save trouble down the road.

Time to set that up while I've got only one local patch to deal with...

> When I make small spot-changes to code (e.g. tab colors), I don't check them in immediately.

This is one place where I get in trouble. Often, I have to stash save / stash pop when switching branches, which is usually straightforward, but sometimes raises a merge conflict and then things get ugly, fast. So I'm thinking I need to be more rigorous, rather than less, about avoiding unstaged changes.

Some really helpful tips here -- much appreciated --
hjh


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

brianlheim
> I would like to have a list of branches at the side, click on one, see the top of that branch's log, and then be able to delete old branches from the list.

This is somewhat of a pain point for me too. On GH I delete branches the moment they're merged. Locally, I've defined a bash function called "gitcb <name>" (git clean from branch) that checks out a branch and deletes any branches that have been merged into it (aka are not useful, at least in my workflow). This is what it is:

gitcb() {
    if [[ -z "$1" ]]; then
        echo "Need branch name."
        exit 1
    fi
    git checkout "$1"
    git branch --merged | grep -v "$1" | xargs git branch -d
}

Git branch --merged shows you the branches that have been merged into the current HEAD already (i.e., that list depends on what branch you currently have checked out). You can also use git branch --sort=committerdate to sort by the time of the last commit to the branch. git branch -v will show the last commit message for each entry as well as the branch's relationship with its tracking branch (behind 5, ahead 3, gone, etc).

Maybe helpful, maybe not, but those are some interesting things maybe not everyone knows.

-Brian



On Fri, Jan 5, 2018 at 9:56 PM, <[hidden email]> wrote:
Thanks again for the suggestions. Looking forward to reading the article Nathan found.

Brian:
> There are some tools out there that assist with performing Github-specific actions from the command line. If you give it a access token that has limited privileges, you should be able to test it out without completely blowing things up.

Hm, for myself, I'm reasonably comfortable with the basics at the commandline (though, as noted the other day, occasionally I drop an argument and get confused).

Specifically, what I'm missing in a GUI is easy browsing of branches to get rid of dead weight. That's another area where I get in trouble -- stale branches stay around, and then I get lost. Qgit lets you view any branch, but the key/mouse sequence is not convenient. I would like to have a list of branches at the side, click on one, see the top of that branch's log, and then be able to delete old branches from the list.

Qgit's commit interface *does* let you preview the diff, and for every commit problem I've complained about, this interface has saved me from hundreds, maybe thousands, of mistakes. I think I'm in good shape there.

Scott C.:
> The gist is, basically: if you're going to have local sandbox-y develop branches, NEVER commit to them directly - always commit to a branch that's semantically meaningful (one that describes how it differs from master / some other parent).

O. M. G.

OK, yeah, that may be a key idea that I missed. I already refuse to commit directly to any branch that's tracking origin or upstream (always topic branch -> push to origin -> PR -> somebody merges it upstream -> fetch upstream -> merge locally)... I didn't think of applying that logic to sandbox branches. Sure. Makes perfect sense, and I can see how that would save trouble down the road.

Time to set that up while I've got only one local patch to deal with...

> When I make small spot-changes to code (e.g. tab colors), I don't check them in immediately.

This is one place where I get in trouble. Often, I have to stash save / stash pop when switching branches, which is usually straightforward, but sometimes raises a merge conflict and then things get ugly, fast. So I'm thinking I need to be more rigorous, rather than less, about avoiding unstaged changes.

Some really helpful tips here -- much appreciated --
hjh

Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

miguel.negrao-lists
In reply to this post by jamshark70-2
On 06-01-2018 02:56, [hidden email] wrote:
> Thanks again for the suggestions. Looking forward to reading the article Nathan found.
>
> Brian:
>> There are some tools out there that assist with performing Github-specific actions from the command line. If you give it a access token that has limited privileges, you should be able to test it out without completely blowing things up.
>
> Hm, for myself, I'm reasonably comfortable with the basics at the commandline (though, as noted the other day, occasionally I drop an argument and get confused).
>
> Specifically, what I'm missing in a GUI is easy browsing of branches to get rid of dead weight.

Hi James,

Sorry I didn't read everything in detail. Personally I find it quite
easy to work with git including doing interactive rebases, normal
rebases, merges, cherrypicnking and conflict merging, but only because I
do all of that from a very capable (cross-platform) gui application:
smartgit. I highly recommend it. I can't imagine having to do all that
from the command line, it would just take too long for me, and require
knowing too many git switches. Don't misunderstand me, to use smartgit
you still have to have a good understanding of the model of git, but the
actual tasks are rendered much easier to perform. Just my 2 cents...

Just to get an ideia changing branch, it automatically stashes and
unstashes changes... It also has a very good interface to browse commits
and branches, see blame or see diff between any two commits.

Best,
Miguel Negrão

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaner local git workflow... suggestions?

jamshark70-2
On January 12, 2018 18:09:29 [hidden email] wrote:

> Sorry I didn't read everything in detail. Personally I find it quite
> easy to work with git including doing interactive rebases, normal
> rebases, merges, cherrypicnking and conflict merging, but only because I
> do all of that from a very capable (cross-platform) gui application:
> smartgit. I highly recommend it.

Hmm, I'll take a look. I like qgit for browsing history and committing, but
it's missing some features.

> Just to get an ideia changing branch, it automatically stashes and
> unstashes changes...

I'm not sure I would want that, actually, I've had too many times when it
threw a merge conflict warning during stash pop.

In any case, I learned a lot from this thread, mainly: simplify, commit
into semantically meaningful branches, and don't leave too many loose
changes sitting around.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com




_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/