Difference between revisions of "Talk:Splash"
(fix formatting of talk page) |
|||
Line 123: | Line 123: | ||
$ splash rebuild rhine/int | $ splash rebuild rhine/int | ||
</nowiki> | </nowiki> | ||
+ | |||
+ | == more questions and answers == | ||
+ | <nowiki>On Thu, Jan 23, 2014 at 08:08:03PM +0100, Bird, Tim wrote: | ||
+ | > Here are some questions: | ||
+ | > | ||
+ | > 1. I'm not entirely sure what the splash.remote configuration is used for. I presume that | ||
+ | > all splashes are relative to this remote repository? Is that correct? | ||
+ | > | ||
+ | |||
+ | The idea for splash.remote is entirely to avoid typing a remote when you | ||
+ | do fetch et al. | ||
+ | |||
+ | > 2. Are there any splash commands that work locally (before or after a fetch-all) | ||
+ | > or do they all require remote access? | ||
+ | |||
+ | Splash is intended to work like git, so most commands are local, only | ||
+ | fetch(all), push and sync utilize the remote. | ||
+ | |||
+ | > | ||
+ | > 3. In the [config] section of the Splashfile, there is a entry for 'base'. | ||
+ | > Does this mean that all splashes in this Splashfile are relative to that base? | ||
+ | |||
+ | Relative, yes. All splashes without dependencies are based on the | ||
+ | 'base' ref only. | ||
+ | |||
+ | > | ||
+ | > 4. I found that you can't do 'splash -h' until splash is configured properly. | ||
+ | > I made a change to my own splash to support showing usage before doing | ||
+ | > some of the sanity checks. Would you be interested in me sending this | ||
+ | > patch? (Actually, I'd like to transfer it using splash and a splash workflow, so | ||
+ | > I can figure out how to do this.) I have a few other changes that I think | ||
+ | > would be good as well. Should I make a refs/topics/timothy.bird/splash-fixes | ||
+ | > topic branch? | ||
+ | |||
+ | Hrm. Obviously neither Bjorn nor I ever tested that. Patches are | ||
+ | welcome, but it is probably best if these are submitted using gerrit, as | ||
+ | this would be the easiest way to share the changes. | ||
+ | |||
+ | > | ||
+ | > 5. I'm still confused about local branch management. Is it intended that | ||
+ | > 'splash fetch' create local branches? It appears not. The commands you sent | ||
+ | > previously show some different ways of creating local branches. Is there a single | ||
+ | > canonical way to create and name a local branch? If so, would it be good for | ||
+ | > splash to enforce that. Right now I do 'splash fetch rhine/int ; splash checkout rhine/int' | ||
+ | > and I get an error message. | ||
+ | |||
+ | Splash fetch is not intended to create branches, but it does create | ||
+ | local refs. I did not want to pollute the local branch setup. If you | ||
+ | want these, and have them updated by splash, you can do: | ||
+ | |||
+ | $ (cd .git/refs/heads/; ln -s ../splash) | ||
+ | |||
+ | > | ||
+ | > Note - it is NOT advisable to create a branch named 'splash' - it interferes with other | ||
+ | > commands that attempt to create refs/heads/splash/... This had me stuck with a bunch | ||
+ | > of errors for a while. | ||
+ | |||
+ | Interesting. That should be fixed. | ||
+ | |||
+ | > | ||
+ | > After a 'splash fetch' I am making individual local branches like so: | ||
+ | > $ git checkout splash/rhine/int | ||
+ | > (... warning about 'detached HEAD' state...) | ||
+ | > $ git checkout -b splash/rhine/int | ||
+ | > | ||
+ | > Does this look reasonable? | ||
+ | |||
+ | Well that will work, but it's not recommended, as the splash ref can | ||
+ | change underneath when you do a splash checkout. | ||
+ | |||
+ | > | ||
+ | > 6. The workflow to set up splash seems a bit odd. Here's what I do: | ||
+ | > * clone repository | ||
+ | > * checkout meta/splash | ||
+ | > * copy splash.py to ~/bin, and symlink to ~/bin/splash | ||
+ | > * copy Splashfile outside repository | ||
+ | > * use splash to check out a splash | ||
+ | > * symlink Splashfile back into the working tree | ||
+ | |||
+ | Yea, the setup kindof sucks for splash. Most of the problem here is | ||
+ | that splash is actually in the kernel repository. This should probably | ||
+ | be fixed somehow. What I do is: | ||
+ | * clone meta/splash into its own repository e.g. ~/code/splash | ||
+ | * ln -s ~/bin/splash ~/code/splash/splash.py | ||
+ | * clone kernel into ~/code/kernel | ||
+ | * ln -s ~/code/splash/Splashfile ~/code/kernel/Splashfile | ||
+ | * cd ~/code/kernel; splash fetch; splash checkout rhine/int | ||
+ | > | ||
+ | > I had to edit Splashfile because one of the splashes was broken. When I change | ||
+ | > trees do I have to remove the Splashfile symlink, checkout another tree, then put | ||
+ | > the symlink back? | ||
+ | |||
+ | Um. No? I'm not sure what you mean by "change trees" here. You can | ||
+ | symlink/copy a Splashfile to many kernel trees. Splash never writes the | ||
+ | Splashfile. | ||
+ | |||
+ | > | ||
+ | > 7. Is there something that tracks which sub-splashes are merged or not merged | ||
+ | > in the working tree? (Kind of like the quilt 'applied' file) | ||
+ | |||
+ | No. It behaves more like git in this case, you can use git/splash to | ||
+ | determine if/what refs/splash/<splash> is merged into your current tree | ||
+ | though: | ||
+ | |||
+ | $ splash log | sed -n \ | ||
+ | '/refs\/splash\//s,.*refs/splash/\([^(,]*\)[,)]*.*,\1,p' | ||
+ | or: | ||
+ | $ git log v3.12.. --oneline --decorate=short | sed -n \ | ||
+ | '/refs\/splash\//s,.*refs/splash/\([^(,]*\)[,)]*.*,\1,p' | ||
+ | |||
+ | This could be a good idea to add as a feature to splash. | ||
+ | |||
+ | > | ||
+ | > 8. Do any of the splash commands update Splashfile, or is this always done manually? | ||
+ | |||
+ | No. Updates are always done manually. This was in the initial design, | ||
+ | but I'm not entirely sure that it's required/needed. | ||
+ | |||
+ | -Courtney</nowiki> |
Revision as of 11:53, 5 January 2015
Here are some notes retrieved from old e-mails (from early 2014). These might be useful in understanding how splash works.
On Wed, Jan 15, 2014 at 08:56:01PM +0100, Bird, Tim wrote: > > When I clone review.sonyericsson.net/kernel/linux-2.6.git, I get a mainline tree. > > I checked out remotes/meta/splash and got a directory with Splashfile and splash.py > Right. What I do is create a seperate directory for splash, and symlink the Splashfile to my working kernel directory, and symlink the splash.py to ~/bin/ > I tried './splash.py checkout rhine/int' and got the following error: > fatal: No tags can describe 'b48d3c2b73d1632f06230bc18e9f93be20445019'. > Try --always, or create some tags. > > Traceback (most recent call last): > File "./splash.py", line 548, in <module> > op_checkout(selection) > File "./splash.py", line 424, in op_checkout > op_rebase(splash) > File "./splash.py", line 412, in op_rebase > depth = splash.depth() > File "./splash.py", line 103, in depth > tag = git.describe(self.localref) > File "./splash.py", line 244, in describe > return git.do("describe", ["--abbrev=0"]) > File "./splash.py", line 254, in do > raise subprocess.CalledProcessError(repo.returncode, cmd, output=err) > subprocess.CalledProcessError: Command '['git', 'describe', '--abbrev=0']' returned non-zero exit status 128 > Yea... You need to fetch the splashes first. Try: $ splash.py fetch rhine/int > If I try to checkout something else, I now get: > > Batch job already in progress, continue or abort first > Yes. Splash has its own batch parser, similar to the one in a git interactive rebase. We actually used to use interactive rebase, but it was slow, and you can't batch rebases that way. If a command fails in any way (other than argument parsing), you will need to execute: $ splash.py abort or $ splash.py continue # to try again > > I feel like I'm missing something simple. I do 'git ls-remote origin' and see the topic refs and their commit ids > but when I try to refer to them I get: > > fatal: ambiguous argument 'ed513dcdabd0e67': unknown revision or path not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git <command> [<revision>...] -- [<file>...]' > > I tried this: > $ git checkout -tb ba-rhine-int origin/refs/topics/bjorn.andersson/3.13-rc6/int > fatal: Cannot update paths and switch to branch 'ba-rhine-int' at the same time. > Did you intend to checkout 'origin/refs/topics/bjorn.andersson/3.13-rc6/int' which can not be resolved as commit? > Yea, this only seems to work for tags, branches, and commits, git has some weird non-shared ref lookup stuff all over the place. According to many tools these aren't valid refs because they aren't under refs/heads/ or refs/tags/. > I finally ended up with this: > $ git fetch origin refs/topics/bjorn.andersson/3.13-rc6/int > fatal: Couldn't find remote ref refs/topics/bjorn.andersson/v3.13-rc6/int > > $ git checkout -b ba-rhine-int FETCH_HEAD Hrm. I'm not sure I follow. Did that fetch fail? > > I think I'm doing this the hard way. Is there a simple way to pull all the topic refs as branches > in my local repository? Well, you can download and have all the splashes as local refs in one of the following ways: * $ splash.py fetch # or fetch-all or fetchall; fetches all splashes * $ splash.py fetch rhine/int # for all splashes rhine/int depends on * $ git fetch origin $(for ref in `sed -n '/^ref/x;s/ref\s*=\s*//p' Splashfile`; do echo "$ref:refs/heads/${ref:12}"; done) # poor man's splash If you do it with splash, they won't be branches, but instead refs in refs/splash/<splash-name>. If you want to turn these into branches, try: $ for splash in `find .git/refs/splash/ -type f`; do git update-ref refs/heads/splash/${splash:17} ${splash:5}; done but keep in mind that these branches will need to be updated every time you change anything in splash. You can also make the ref a symlink instead to fix this, but I'll leave that as an exercise for the reader. > > -- Tim > As a general rule, working with splash works like so: $ splash.py fetch rhine/int # edit Splashfile to add splash 'my-feature' $ splash.py start my-feature # make / add commits $ git update-ref refs/splash/my-feature HEAD $ splash.py push my-feature At any point you can also do: $ splash.py merge rhine/int # test $ splash.py unmerge rhine/int If you change dependencies in the Splashfile, such as adding 'my-feature' to the rhine/int deps, you'll need to execute: $ splash rebuild rhine/int
more questions and answers
On Thu, Jan 23, 2014 at 08:08:03PM +0100, Bird, Tim wrote: > Here are some questions: > > 1. I'm not entirely sure what the splash.remote configuration is used for. I presume that > all splashes are relative to this remote repository? Is that correct? > The idea for splash.remote is entirely to avoid typing a remote when you do fetch et al. > 2. Are there any splash commands that work locally (before or after a fetch-all) > or do they all require remote access? Splash is intended to work like git, so most commands are local, only fetch(all), push and sync utilize the remote. > > 3. In the [config] section of the Splashfile, there is a entry for 'base'. > Does this mean that all splashes in this Splashfile are relative to that base? Relative, yes. All splashes without dependencies are based on the 'base' ref only. > > 4. I found that you can't do 'splash -h' until splash is configured properly. > I made a change to my own splash to support showing usage before doing > some of the sanity checks. Would you be interested in me sending this > patch? (Actually, I'd like to transfer it using splash and a splash workflow, so > I can figure out how to do this.) I have a few other changes that I think > would be good as well. Should I make a refs/topics/timothy.bird/splash-fixes > topic branch? Hrm. Obviously neither Bjorn nor I ever tested that. Patches are welcome, but it is probably best if these are submitted using gerrit, as this would be the easiest way to share the changes. > > 5. I'm still confused about local branch management. Is it intended that > 'splash fetch' create local branches? It appears not. The commands you sent > previously show some different ways of creating local branches. Is there a single > canonical way to create and name a local branch? If so, would it be good for > splash to enforce that. Right now I do 'splash fetch rhine/int ; splash checkout rhine/int' > and I get an error message. Splash fetch is not intended to create branches, but it does create local refs. I did not want to pollute the local branch setup. If you want these, and have them updated by splash, you can do: $ (cd .git/refs/heads/; ln -s ../splash) > > Note - it is NOT advisable to create a branch named 'splash' - it interferes with other > commands that attempt to create refs/heads/splash/... This had me stuck with a bunch > of errors for a while. Interesting. That should be fixed. > > After a 'splash fetch' I am making individual local branches like so: > $ git checkout splash/rhine/int > (... warning about 'detached HEAD' state...) > $ git checkout -b splash/rhine/int > > Does this look reasonable? Well that will work, but it's not recommended, as the splash ref can change underneath when you do a splash checkout. > > 6. The workflow to set up splash seems a bit odd. Here's what I do: > * clone repository > * checkout meta/splash > * copy splash.py to ~/bin, and symlink to ~/bin/splash > * copy Splashfile outside repository > * use splash to check out a splash > * symlink Splashfile back into the working tree Yea, the setup kindof sucks for splash. Most of the problem here is that splash is actually in the kernel repository. This should probably be fixed somehow. What I do is: * clone meta/splash into its own repository e.g. ~/code/splash * ln -s ~/bin/splash ~/code/splash/splash.py * clone kernel into ~/code/kernel * ln -s ~/code/splash/Splashfile ~/code/kernel/Splashfile * cd ~/code/kernel; splash fetch; splash checkout rhine/int > > I had to edit Splashfile because one of the splashes was broken. When I change > trees do I have to remove the Splashfile symlink, checkout another tree, then put > the symlink back? Um. No? I'm not sure what you mean by "change trees" here. You can symlink/copy a Splashfile to many kernel trees. Splash never writes the Splashfile. > > 7. Is there something that tracks which sub-splashes are merged or not merged > in the working tree? (Kind of like the quilt 'applied' file) No. It behaves more like git in this case, you can use git/splash to determine if/what refs/splash/<splash> is merged into your current tree though: $ splash log | sed -n \ '/refs\/splash\//s,.*refs/splash/\([^(,]*\)[,)]*.*,\1,p' or: $ git log v3.12.. --oneline --decorate=short | sed -n \ '/refs\/splash\//s,.*refs/splash/\([^(,]*\)[,)]*.*,\1,p' This could be a good idea to add as a feature to splash. > > 8. Do any of the splash commands update Splashfile, or is this always done manually? No. Updates are always done manually. This was in the initial design, but I'm not entirely sure that it's required/needed. -Courtney