Difference between revisions of "Talk:Splash"

From eLinux.org
Jump to: navigation, search
(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