do any git tools work like this?

[David Schwartz 426]

Many folks here have seen the various missives I've posted over the past 6 months or so trying to deal with learning the weirdness of git (my perception). I still don't know if it's just how my workplace does things or if we're not using git as the designers envisioned, but I have not run into many folks who seem to deal with stuff the same way we do. 

 

One of the things that seems to be at the root of my issues is the disconnect between git and work activities. We have a ticket-based workflow where our Cust Svc people create work tickets based on customer needs and post them to a few different ticketing systems we support (including Jira).  It's a very dynamic environment, and we can end up switching between different activities several times a day. It turns out that tracking git branches by naming them for the ticket numbers we're working on works well for our needs.

 

The problem is, we can be on a meeting and questions will come up about different tickets and issues that I or others may be having, so I find myself switching from one ticket to another to another. Delphi doesn't know anything about tickets, nor does git or any other tool. But if I've been working in a git branch and make some changes to files in a folder for a given ticket, then I switch context, work can literally disappear if I change git branches without committing my work. Even worse, uncommitted work can inadvertently get attached to the wrong ticket / branch if I'm not really careful about what I'm committing when I do a context switch.

 

In a nutshell, my work activities are highly interrupt-driven with lots of context switches throughout the day, so it's very easy for git to become out-of-sync with the work I need to focus on.

 

I ended up building a tool that is designed around the notion of these "tickets". In most respects, a "ticket" is just a name with associated tasks, a client and one or more working folders. There's also a git branch named after it as well.

 

So when I switch tickets in this "workbench", it does a full context switch for me: it pulls up notes, lists, related folders, and changes the git branch. 

 

One thing that's interesting about it is that if I try to switch to another ticket and git detects a conflict, it won't switch branches. I have to go in and do a commit or a stash, which is actually a very quick operation that's built into the workbench. This alone has saved my butt several times, because I'll usually either forget to change branches, or I'll not want to deal with the commit because it's just an interrupt. 

 

Delphi doesn't care, but once in a while I'll switch tickets with a project open in Delphi and when I go back to Delphi it will alert me that the underlying file(s) have changed. This is the problem that has caused us so much grief in the past where files get overwritten without our real understanding what was going on. (Delphi simply reflects the underlying file changes that switching branches often entails.)

 

Anyway, I've seen lots of GUI tools for git, but they're all focused around git and git's workflow. We don't really deal with git, or even care about git's workflow at work. We deal with things the customers want, and these "wants" are enshrined in what we call "tickets". Our workflow focuses on tickets. Git ends up being more of an annoyance than anything else, like a pet that's always jumping into your lap when you're trying to do something else, and they hit the keyboard with their paw and wreak havoc while you're trying to put your coffee down without spilling it all over the place.

 

The workbench I've created bridges the gap between having git branches being out-of-sync with work activities, and it works incredibly well. It has a bunch of git functions built-in that make it super easy to keep everything straight.

 

I'm curious if anybody is aware of any general purpose tools that might do this. If not, I may be able to generalize this in places so it would be more broadly accessible to others.

 

(FWIW, it is not integrated into any ticketing systems we have -- they don't let us do that. So "tickets" in this context are simply what we use to name working contexts. There are a few things highly specific to our environment that could probably be made configurable, but for the most part, it's quite generic.)

 

 

Edited November 11, 2020 by David Schwartz

[Anders Melander 1783]

Once again: As far as I can tell there's nothing special in the work flow your describe. It's perfectly normal to have a branch per ticket, to change branch several times a day, to get interrupted while you're working on something that hasn't yet been committed, etc. The problems with Git you describe (changes disappearing, etc) are not problems with Git but with the way you use it; It will not overwrite your uncommitted changes unless you force it to.

 

It is unclear to me what benefits your tool provides. It sounds like the problems it solves are already handled by the existing GUI Git clients.

[Stefan Glienke 2002]

Must be very unproductive and frustrating the way you handle things - it is known that humans are terrible at context switching.

[David Schwartz 426]

Hmmmm ... I'm not sure what I'm missing.

 

There are two devs who have been using git for many years, but they're web devs. They can't wrap their heads around having a dozen or more files in our source tree that are just "compiler artifacts" (eg., dcu and other similar files) that don't need to be maanged by git. They think our whole set up is extremely convoluted.

 

I didn't set up anything we're working with. It was done by people 10+ years ago who are long gone. There's no documentation, and a variety of opinions about how things ought to work. Nobody is really sure, so we experiment and tend to follow the path of least resistance.

 

I feel lucky when things work the way I expect. 🙂

[Anders Melander 1783]

7 minutes ago, David Schwartz said:

They can't wrap their heads around having a dozen or more files in our source tree that are just "compiler artifacts" (eg., dcu and other similar files) that don't need to be maanged by git.

Apparently they haven't discovered that you can .gitignore files?

 

10 minutes ago, David Schwartz said:

we [...] follow the path of least resistance.

I think we must have different definitions of "least resistance"

[Lars Fosdal 1792]

Is people happy with the situation?
If not - refactor.

Make it right.

If people don't want to, they lose the right to complain.