Git refreshing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Git refreshing

Peter Uhnak
Hi,

I'm facing a problem with branches and refreshing the code. Currently I handle (except for commits) everything from commandline, but the problem is that when I switch branches I don't know how to easily refresh the code. What I am doing now is running loading Baseline again, but that feels odd.

Git revolves around branches, and being able to quickly create them, switch them, and merge them is important.

So is there currently any solution that could resolve this? Maybe I could run some code that would simply load what is on the disk? If I switch branches for java code, the editor automatically loads new content without me needing to do any extra work; it would be nice to have something similar.

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Git refreshing

Thierry Goubier
Hi Peter,

Le 01/03/2015 17:00, Peter Uhnák a écrit :
> Hi,
>
> I'm facing a problem with branches and refreshing the code. Currently I
> handle (except for commits) everything from commandline, but the problem
> is that when I switch branches I don't know how to easily refresh the
> code. What I am doing now is running loading Baseline again, but that
> feels odd.

Not so odd, in truth. It looks like a perfectly fine solution, which,
maybe, could be added to the concept of baseline in a repository.

> Git revolves around branches, and being able to quickly create them,
> switch them, and merge them is important.
>
> So is there currently any solution that could resolve this? Maybe I
> could run some code that would simply load what is on the disk? If I
> switch branches for java code, the editor automatically loads new
> content without me needing to do any extra work; it would be nice to
> have something similar.

Well, as you have noticed in Java, C or C++, switching branches does not
call make automatically :)

In Pharo, loading code means compiling it, so what you describe may be a
bit harder to do. However, if we consider, as above, that working in
different branches is linked to a "project" concept, with a baseline
describing this project and its dependencies, then:

a baseline branch switch could mean: unload the current baseline, its
dependencies, followed by the switch branch, followed by a load of the
baseline (in the new branch).

On the git side, this wouldn't be hard to do.

Another approach, a tad simpler, would be : switch branch, then all
packages already loaded in the image and existing in the branch are
loaded with the head of the new branch. This one would be easy to
implement with just a button "switch branch" in the GitFileTree
repository inspector.

Thierry



Reply | Threaded
Open this post in threaded view
|

Re: Git refreshing

Peter Uhnak


On Sun, Mar 1, 2015 at 8:58 PM, Thierry Goubier <[hidden email]> wrote:
Hi Peter,

Le 01/03/2015 17:00, Peter Uhnák a écrit :
Hi,

I'm facing a problem with branches and refreshing the code. Currently I
handle (except for commits) everything from commandline, but the problem
is that when I switch branches I don't know how to easily refresh the
code. What I am doing now is running loading Baseline again, but that
feels odd.

Not so odd, in truth. It looks like a perfectly fine solution, which, maybe, could be added to the concept of baseline in a repository.

Git revolves around branches, and being able to quickly create them,
switch them, and merge them is important.

So is there currently any solution that could resolve this? Maybe I
could run some code that would simply load what is on the disk? If I
switch branches for java code, the editor automatically loads new
content without me needing to do any extra work; it would be nice to
have something similar.

Well, as you have noticed in Java, C or C++, switching branches does not call make automatically :)
You can use git hooks for that.
 

In Pharo, loading code means compiling it, so what you describe may be a bit harder to do. However, if we consider, as above, that working in different branches is linked to a "project" concept, with a baseline describing this project and its dependencies, then:

a baseline branch switch could mean: unload the current baseline, its dependencies, followed by the switch branch, followed by a load of the baseline (in the new branch).
This will not do. :( What if I am working on something and I want to switch branch before committing? Or stashing them somewhere? Right now I don't even see how I could use stash at all.
 

On the git side, this wouldn't be hard to do.

Another approach, a tad simpler, would be : switch branch, then all packages already loaded in the image and existing in the branch are loaded with the head of the new branch. This one would be easy to implement with just a button "switch branch" in the GitFileTree repository inspector.
I will have to think about it. I am used to my git workflow and now I am kind of lost how to use it properly from Pharo; since I am cut off from git. One idea that is crossing my mind is having synchronized filedumps (filetree) in a folder and not worry about git or monticello inside Pharo at all. (And when I change code outside it would magically change also inside).

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Git refreshing

Thierry Goubier
Hi Peter,

Le 03/03/2015 19:29, Peter Uhnák a écrit :

>
>
> On Sun, Mar 1, 2015 at 8:58 PM, Thierry Goubier
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>         So is there currently any solution that could resolve this? Maybe I
>         could run some code that would simply load what is on the disk? If I
>         switch branches for java code, the editor automatically loads new
>         content without me needing to do any extra work; it would be nice to
>         have something similar.
>
>
>     Well, as you have noticed in Java, C or C++, switching branches does
>     not call make automatically :)
>
> You can use git hooks for that.

Ok. Then I would suggest you take the code source of CLANG, LLVM,
OpenOffice or of the Linux kernel, you add the git hooks to call make,
and you admire how fast changing branches becomes ;)

>     In Pharo, loading code means compiling it, so what you describe may
>     be a bit harder to do. However, if we consider, as above, that
>     working in different branches is linked to a "project" concept, with
>     a baseline describing this project and its dependencies, then:
>
>     a baseline branch switch could mean: unload the current baseline,
>     its dependencies, followed by the switch branch, followed by a load
>     of the baseline (in the new branch).
>
> This will not do. :( What if I am working on something and I want to
> switch branch before committing? Or stashing them somewhere? Right now I
> don't even see how I could use stash at all.

Want to switch branches before committing? Can do.

Want to stash? Can be added, instead of committing automagically.

Remember that GitFileTree is about providing a support to allow one to
experiment on the appropriate workflow: it is an enabler, not a
one-size-fit-all solution.

I'm not a git expert, but I know enough about git (and git users:)) that
each and everyone may have its opinion on the way git should be used,
and, as such, I've decided on GitFileTree that I wouldn't claim to hold
the way it should be used™.

>
>     On the git side, this wouldn't be hard to do.
>
>     Another approach, a tad simpler, would be : switch branch, then all
>     packages already loaded in the image and existing in the branch are
>     loaded with the head of the new branch. This one would be easy to
>     implement with just a button "switch branch" in the GitFileTree
>     repository inspector.
>
> I will have to think about it. I am used to my git workflow and now I am
> kind of lost how to use it properly from Pharo; since I am cut off from
> git. One idea that is crossing my mind is having synchronized filedumps
> (filetree) in a folder and not worry about git or monticello inside
> Pharo at all. (And when I change code outside it would magically change
> also inside).

Please explore the idea; just try to focus on that:

- GitFileTree is just about keeping in sync Monticello and Git in a
reasonable way, and understanding what is inside a Git repository.

- Any git action (and you know which ones you are using), is just a few
lines of Smalltalk (except the part where it reads and remap the git
history to MC). Change is easy and cheap.

- There is a whole world of finding the right concepts you use in your
development (stashing, fast branch switching, etc) that we have to explore.

And remember that some of the things I am proposing is just throwing
ideas around to try to see if they fit. Don't be afraid to experiment.

At the same time, there is just me and Max (and Esteban as well, I
think) working on getting that git support working, so don't bash us too
much. It's hard enough to get it done (look at Max questions about
libcgit) that we don't need too much additional pressure.

Thierry

Reply | Threaded
Open this post in threaded view
|

Re: Git refreshing

Peter Uhnak
    Well, as you have noticed in Java, C or C++, switching branches does
    not call make automatically :)

You can use git hooks for that.

Ok. Then I would suggest you take the code source of CLANG, LLVM, OpenOffice or of the Linux kernel, you add the git hooks to call make, and you admire how fast changing branches becomes ;)
Sure; large project would take long regardless but comparatively small (~10kloc) project would get checkouted fast, also it doesn't just completely rewrite the filesystem, but only the actual changes (which is for my use cases most of the time in the order of tens of files)
 
Want to switch branches before committing? Can do.
How? :-o If I switch the branch from git (command line) then there is disparity. 

I'm not a git expert, but I know enough about git (and git users:)) that each and everyone may have its opinion on the way git should be used, and, as such, I've decided on GitFileTree that I wouldn't claim to hold the way it should be used™.
Yes, I need to think about myself a bit... I am used to certain workflow and I guess I was greedy with wanting everything.
 
I will have to think about it. I am used to my git workflow and now I am
kind of lost how to use it properly from Pharo; since I am cut off from
git. One idea that is crossing my mind is having synchronized filedumps
(filetree) in a folder and not worry about git or monticello inside
Pharo at all. (And when I change code outside it would magically change
also inside).

Please explore the idea; just try to focus on that:
Adding it my (endless) todolist, I would need to learn a bit (=lot) about monticello first and how these things actually work inside Pharo so it could be done, but just like everybody I have a lot on my plate. (And I have also tend to eat more than I can chew.)

At the same time, there is just me and Max (and Esteban as well, I think) working on getting that git support working, so don't bash us too much. It's hard enough to get it done (look at Max questions about libcgit) that we don't need too much additional pressure.
I am really sorry if my message sounded harsh, I in no way intended something like that. Sometimes I am more greedy and picky about software than I should be. I'll add some positive emoticons next time so it will be more happy. :)
I am grateful for the work you have done, after all I do like it and I am happy I was able to make the switch to git, despite me missing features; so please don't my ramblings as bashing, they were intended (albeit bit directly) only as questions/ideas.

Peter

Reply | Threaded
Open this post in threaded view
|

Re: Git refreshing

Thierry Goubier


2015-03-03 23:38 GMT+01:00 Peter Uhnák <[hidden email]>:
    Well, as you have noticed in Java, C or C++, switching branches does
    not call make automatically :)

You can use git hooks for that.

Ok. Then I would suggest you take the code source of CLANG, LLVM, OpenOffice or of the Linux kernel, you add the git hooks to call make, and you admire how fast changing branches becomes ;)
Sure; large project would take long regardless but comparatively small (~10kloc) project would get checkouted fast, also it doesn't just completely rewrite the filesystem, but only the actual changes (which is for my use cases most of the time in the order of tens of files)

As GitFileTree stands, some things are easy to do; others could be added. Note that: GitFileTree makes it easy to browse a specific commit without touching or branching or checking out the repository.
 
 
Want to switch branches before committing? Can do.
How? :-o If I switch the branch from git (command line) then there is disparity. 

Well, yes and no. What you are working on is stashed inside your image (your current working copy). That you change, branch or checkout the underlying git repository doesn't matter. On a refresh or the repository inspector, GitFileTree will pick all the changes without any perturbation on your working copy.

You have to understand that Monticello coupling of a package with a repository is very loose. Each time you do something with Monticello, it won't go straight for the repository the package came from, but instead will scan all repositories if they have something relevant.

I'll try to rephrase, maybe it'll be clearer.

Your working copy in the Pharo image (the modified package you are working on) is, to take a git concept, your staging area / changes to head.

If you checkout / change branch / pull the git repository, you make the equivalent of stash, git checkout, and recreate your changes on top of the new HEAD (not exactly like that, but this is how GitFileTree will map your changes to git).

By the way, for FileTree users: FileTree does the same thing... but with next to zero control over the git status.
 

I'm not a git expert, but I know enough about git (and git users:)) that each and everyone may have its opinion on the way git should be used, and, as such, I've decided on GitFileTree that I wouldn't claim to hold the way it should be used™.
Yes, I need to think about myself a bit... I am used to certain workflow and I guess I was greedy with wanting everything.

Maybe also I'm not very clear about the interaction between Monticello and Git.
 
 
I will have to think about it. I am used to my git workflow and now I am
kind of lost how to use it properly from Pharo; since I am cut off from
git. One idea that is crossing my mind is having synchronized filedumps
(filetree) in a folder and not worry about git or monticello inside
Pharo at all. (And when I change code outside it would magically change
also inside).

Please explore the idea; just try to focus on that:
Adding it my (endless) todolist, I would need to learn a bit (=lot) about monticello first and how these things actually work inside Pharo so it could be done, but just like everybody I have a lot on my plate. (And I have also tend to eat more than I can chew.)

I would say, probably not that much about Monticello.

But it could be nice if we make the minimum a bit clearer, such as documenting a few entry points (load a package, save a package, list all dirty packages, etc...)

What we need more, is things along the lines of:

- If I do operation A in my git repository, I want my image Monticello to do X

- If I do operation B in Monticello, I want my git repository to do the operation Y

Once we have a list like that, we can: add ways to trigger X when A was done (or add a button in Pharo to do A, followed by X), and, when doing B in MC, have GitFileTree do Y.
 
 

At the same time, there is just me and Max (and Esteban as well, I think) working on getting that git support working, so don't bash us too much. It's hard enough to get it done (look at Max questions about libcgit) that we don't need too much additional pressure.
I am really sorry if my message sounded harsh, I in no way intended something like that. Sometimes I am more greedy and picky about software than I should be. I'll add some positive emoticons next time so it will be more happy. :)
 
I am grateful for the work you have done, after all I do like it and I am happy I was able to make the switch to git, despite me missing features; so please don't my ramblings as bashing, they were intended (albeit bit directly) only as questions/ideas.

If I can convince you to help me, then that will be great :)

Thierry
Reply | Threaded
Open this post in threaded view
|

Re: Git refreshing

stepharo
In reply to this post by Thierry Goubier

> At the same time, there is just me and Max (and Esteban as well, I
> think) working on getting that git support working, so don't bash us
> too much. It's hard enough to get it done (look at Max questions about
> libcgit) that we don't need too much additional pressure.

Thanks for that.
Git is too complex for me, I feel dumb so this is good to know that you
guys are spending time on that.

Reply | Threaded
Open this post in threaded view
|

Re: Git refreshing

philippeback
I moved my workflow to use git with Pharo.

Took a while but can't go back.

e.g. of collaboration
https://github.com/flow-stack/Mapless/pull/13/files

Phil

On Sun, Mar 15, 2015 at 10:14 PM, stepharo <[hidden email]> wrote:

>
>> At the same time, there is just me and Max (and Esteban as well, I think)
>> working on getting that git support working, so don't bash us too much. It's
>> hard enough to get it done (look at Max questions about libcgit) that we
>> don't need too much additional pressure.
>
>
> Thanks for that.
> Git is too complex for me, I feel dumb so this is good to know that you guys
> are spending time on that.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Git refreshing

Thierry Goubier
I also believe that baselines + git branches and tags would simplify a
lot complex projects configurations (Moose?).

Thierry

Le 15/03/2015 22:24, [hidden email] a écrit :

> I moved my workflow to use git with Pharo.
>
> Took a while but can't go back.
>
> e.g. of collaboration
> https://github.com/flow-stack/Mapless/pull/13/files
>
> Phil
>
> On Sun, Mar 15, 2015 at 10:14 PM, stepharo <[hidden email]> wrote:
>>
>>> At the same time, there is just me and Max (and Esteban as well, I think)
>>> working on getting that git support working, so don't bash us too much. It's
>>> hard enough to get it done (look at Max questions about libcgit) that we
>>> don't need too much additional pressure.
>>
>>
>> Thanks for that.
>> Git is too complex for me, I feel dumb so this is good to know that you guys
>> are spending time on that.
>>
>>
>
>