-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Vladimir,
Am Do den 14. Apr 2011 um 22:44 schrieb Vladimir Nadvornik:
> I started to hack Geeqie again and now I have a series of patches for
> stereo image support. The patches also implements a base for future
> improvements of image loading and rendering.
Nice to see you back.
> The patches are currently in my local git. Since this is my first project
> with
> git, I would need some advice how to push it to Gitorious, whether use
> separate branch, etc. IMHO git provides too much flexibility here ;)
Well, maybe I can give some hints. Ask if they are not detailed enough.
- - Only tracking branches gets pushed to the server per default. You
start a tracking branch by »checkout -b whatever
origin/upstreambranch« or by editing .git/config.
- - To push a completely new branch or only one, use it explicit: »git
push origin yourgreatbranch« or »git push origin
yourgreatlocalbranch:boringbranchnameinpublic«
- - Stay at the edge of all remotes: »git remote update« (Do not push,
only pull, but all remotes not only one.)
- - Use branches local (not tracked) to implement a feature but merge it
in the tracked branch after finishing. Afterwards you can delete your
own branch but the full history can be seen when you push.
- - Use rebase only on your own branches locally. Never rebase tracking
branches after you push them. It produce a mess if you do as all
others have your original branchhead. (However, that can be solved but
you should omit.)
- - Use origin/master for current development. And use a own origin branch
for your own work that you want other to see too (experimental or not
finished stuff. You might rebase on that but try to omit it as I
explained above). I propose to use release branches for relased
versions and fixes or release work.
A real example. At the moment I have the following structure local:
- - master -- My tracking branch for origin/master
- - ke -- My private branch with stuff I open to other. As I pushed that
name it is also the tracking branch for origin/ke. I use merges or
even cherry-picks to populate that tree. To revoke commits that are
erroneous I use revert.
- - ke-lua -- My feature branch for the unfinished lua feature. As it
might be interesting for other even in that early state I also pushed
it.
- - debian-529531 -- a local branch I use to fix a debian bug. I will
never push it upstream but merge it into master when it is finished. I
might use rebase or commit --amend here as it doesn't destroy pushed
history.
- - Then I have different remotes with all the branches they have:
github git://github.com/zas/geeqie_zas.git (fetch)
github g...@github.com:zas/geeqie_zas.git (push)
gitorious g...@gitorious.org:geeqie/geeqie.git (fetch)
gitorious g...@gitorious.org:geeqie/geeqie.git (push)
origin ssh://tschil.ethgen.ch/~/git/geeqie.git (fetch)
origin ssh://tschil.ethgen.ch/~/git/geeqie.git (push)
sf git://geeqie.git.sourceforge.net/gitroot/geeqie/geeqie (fetch)
sf m...@geeqie.git.sourceforge.net/gitroot/geeqie/geeqie (push)
As you can see, origin points on my own server where I have a similar
layout and a hook that pushes all my work to all (at the moment github
and gitorious) upstream repositories.
My config (the relevant parts) looks like:
[remote "origin"]
url = ssh://tschil.ethgen.ch/~/git/geeqie.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "github"]
url = git://github.com/zas/geeqie_zas.git
pushurl = g...@github.com:zas/geeqie_zas.git
fetch = +refs/heads/*:refs/remotes/github/*
[remote "sf"]
url = git://geeqie.git.sourceforge.net/gitroot/geeqie/geeqie
fetch = +refs/heads/*:refs/remotes/sf/*
pushurl = m...@geeqie.git.sourceforge.net/gitroot/geeqie/geeqie
[remote "gitorious"]
url = g...@gitorious.org:geeqie/geeqie.git
fetch = +refs/heads/*:refs/remotes/gitorious/*
pushurl = g...@gitorious.org:geeqie/geeqie.git
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "ke"]
remote = origin
merge = refs/heads/ke
[branch "ke-lua"]
remote = origin
merge = refs/heads/ke-lua
Note the three branch sections, that are my tracking branches. You might
use other names for remotes or your tracking branches.
What I not mention here is to use special remotes like bundles or local
available checkouts in $HOME of others to even have work that is shared
between people not working in the global repository.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <kl...@ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTageap+OKpjRpO3lAQo0Iwf/WdWJhDGRQ048MB7OdDuZArOQmz6bEHCZ
24exKfTuBNAmHNBqEzUiMld4F2uoHI/GRdMQE3vd2aSMht08/LU2wngDLIZr3LpZ
aGu/rOH4RIOU/MKZWaQk5ySVc4mlfDnV6HsoFNMd9zoM2HKJualXhhQG/ukWJn+B
Nc4LLfclBqzmDBt7w44CqZ0zg9FlHvBfRBYVE0sVAEK5DIma6gYxUoyem6bJrtIp
I2GWaW66NOf/KFjjd1Q7tgEpe/18flJlXqgABt4g7S0+gmw7fu+Tzuf1nwaugeqt
ZdRUG8Q8e6quV+cWuLoRUomhHa/z9o4eQj1VQerK0yUGTN+YVilynw==
=5c5U
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
