Re: On the adoption of transient.el

[Arthur Miller]

John Yates <john@yates-sheets.org> writes:

> On Sat, Aug 14, 2021 at 8:55 AM Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Arthur Miller <arthur.miller@live.com> writes:
>> > The strategy is to stash save all buffers belonging to the project,
>> > stash everything, inclusive untracked files, and than checkout to the
>> > other branch. When checked back, the stash is applied back. I don't know
>> > if you have something like that in magit or if it is something generally
>> > desirable, but I always wanted something simple and dirty to be able to
>> > switch fast when I need it.
>>
>> How would Magit know that when you "return back" to a branch it must
>> apply a certain stash?
>
> Rather than use a stash I would have a script that does two things:
> * Creates an undo script for the next step
> * Saves everything important as a new commit on the current branch.
>   This would include, among other things, all untracked files and the
>   undo script mentioned in the first step.

I had thoughts of implementing commit strategy too :-). I even have
prepared a variable that I have planned to use for this. My motivation
was mostly to see if it is somewhat faster than stashing and reaplying
changes, but I haven't really got to that yet.

After more thoughts I am also not sure if that would be any better than
stash to be honest. Stashes are meant for something like this, and it is
a normal strategy people use. Can you give me some reason why would it
be better to commit changes instead of stashing away them?

When it comes to tracked/untracked files, I do have from the beginning a
variable to switch what is stashed away. I agree with what you wrote in
your last replay, that it is not always desirable to stash untracked
files. I was just not in the mood for explaining in details what I am
doing, so I wrote just very short notice to not use this strategy :).

> Now with the workspace in a clean state you can switch away to some

Isn't that what stashing away also does?

> other branch.  When you return to the original branch you run the undo
> script.  It backs out the last commit.  This would included performing
>
>     git rm --cached <all originally untracked files>

I do delete the stash after applying it. Pop can't be reliably used in
an automated script like this, so I apply the specially named stash and
than throw it away, which si similar to pop.

> * Creates an undo script for the next step

The undo script would be an interesting addition indeed. I am not sure
if we think of same thing, but what I am doing is saving all open and
modified file buffers belonging to git root and subfolders, before I do
stashing. What would be nice, is to undo saved changes in buffers that
were modified, so that they appear as modified after checking out old
branch again. Currently they are just saved, so when they are checked
out again, they don't appear as modified again.

I am not sure where to look to implement something like that, is there
some variable in buffer I can check for modifications sine last save, so
I could use it to save some state somewhere?

Thanks you for the comment, this was constructive.

If you are interested to take a look I have attached the code, and the
poject is here with some additional info in readme:

https://github.com/amno1/helm-git-branch

helm-git-branch.el
Description: Text document