On Oct 25, 2007, at 12:27 PM, Johannes Schindelin wrote:
Hi,
On Thu, 25 Oct 2007, Steffen Prohaska wrote:
On Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote:
On Thu, 25 Oct 2007, Steffen Prohaska wrote:
On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
[...]
But here is a proposal which should make you and your developers
happy, _and_ should be even easier to explain:
Work with topic branches. And when you're done, delete them.
Again, if you want to share the topic branch the situation gets
more
complex.
Hardly so. In my proposed solution to your problem, there is
nothing
which prevents you from working off of another branch than "master".
Well if you have several local branches checked out that are
shared with others you run into the "git push" problem again ...
(see below at git push origin master).
Do the same as I, always say "git push origin master" (of course, you
should exchange "master" with whatever branch you want to push). Be
precise.
Well, I'm lazy. git already knows everything. It knows that
the current branch is associated with a specific remote and it
pushes matching branches by default. And I took care to not
pollute the namespace. All my branches are named identical
in all repositories I'm dealing with. It's reasonable to want
"git push" to do the right thing.
So the beginning of the day could look like this:
git fetch
git checkout -b todays-topic origin/master
[hack hack hack]
[test test test]
[debug debug debug]
[occasionally commit]
[occasionally git rebase -i origin/master]
and the end of the topic
git branch -M master
Isn't this a bit dangerous? It forces to overwrite master no matter
what's on it. You don't see diffstats nor a fast forward message that
confirms what you're doing.
Yeah, I should have said something like "git branch -m master"
(implicitely assuming that you have no current "master" branch).
git push origin master
I'd like to see "git push" here.
I think it is not asking too much for the user to be a bit more
precise.
If you really do not trust your developers to be capable of that,
point
them to git gui.
Well I was more precise and got lazy over time. Now the most I do
is "git push --dry-run" and if it looks good I do "git push".
Most of the time I just say "git push".
As I pointed out earlier, "git push origin <some-branch>" can create
a new branch on the remote. "git push" never creates a new branch.
I believe "git push" is safer.
git branch -m <shared_branch>
git push origin <shared_branch>
git checkout do-not-work-here
git branch -D <shared_branch>
Actually, the last two commands would better be
git checkout HEAD^{commit}
git branch -d <shared_branch>
Wow, looks weird (not too me but to someone who doesn't know git).
The problem I see here: you know git quite well. Others don't, and
will be mightily confused why pull updates local branches sometimes,
and sometimes not.
But it already happens now. "git pull" sometimes merges a remote
branch
(--track) and sometimes it reports an error that is fails to do so
(--no-track).
If there really is an inconsistent behaviour, then we'll have to
fix that.
We should not introduce inconsistent behaviour on top of that.
It's not inconsistent. It's an option of a branch. Git supports two
flavours of local branches. Some branches automatically merge and other
don't.
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
