On Thursday 25 March 2010 21:57:46 Ximin Luo wrote:
> My point is that there should be (and the only way to do that is to have a
> shared repository, because only repositories grant access). It's tedious to
> create a new branch just to do a one-off bug fix, and tedious to one-commit
> pulls from 5 separate branches.
No, it?s not. Unless of course actually using a VCS system is already tedious
for you. :)
git branch fix
git add fixed-file
git commit -m "Fix"
The official maintainer now does:
git fetch url|remote fix
There?s nothing tedious about it. When everybody would push into the branch
toad is also developing in he has to pull and merge that first before he can
do anything else. This bears a lot more potential for confusion.
> So what do you mean by a staging branch? A branch that needs a core dev to
> pull into, but which doesn't need to be reviewed? What's the point of
> that? Why not just pull only when you've reviewed it?
I mean exactly what I described in my first mail. Thank you for reading it. :)
Currently we use a tag for the commit that toad last reviewed. My proposed
model would simply use a branch for the job. Instead of tagging a commit as
?reviewed-123? toad would just move the branch pointer, i.e. "git checkout
stable; git reset --hard <commit>", followed by a push to the repository. The
current development branch is not touched by this at all.
This would also have the advantage that the latest reviewed code is always
available under a fixed URL, there?s no need to search for the tag that looks
like the most recent.
> X
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20100325/79dde5a4/attachment.pgp>
