From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:45
Steffen Prohaska [off-list ref] writes:
quoted
You forgot a lot more important part. Pushing into publishing
repositories. And the discussion is about git-push command.
Exactly, here are two examples:
If you push only to publishing repositories that are read
only by others, you'll never encounter the problem that
10/10 tried to solve. The publishing repository is never
changed by others. You are the only one who pushes to this
repository. Therefore the remote never advances unexpectedly.
Wrong.
People can and do work from more than one private repositories
(I do). In a sense, that is sharing the repository with
oneself.
I may do an emergency patch to fix breakage on 'maint' (and
'maint' only) from a location that is not my primary development
box and push the fix out. I fully expect that the push will
push out 'maint' and expect the other branches such as 'master'
on the remote side to stay the same, as I haven't touched
'master' on that box for quite a while and it is now stale. In
that situation, I _want_ the "git push" itself to report failure
to notify me that it did not push what _I_ asked it to push out,
so that I can be reminded that I'd better do "git push $remote
maint" the next time. In the meantime, even though it reports
a failure, 'master' on the remote side is _not_ updated, so the
behaviour is still _safe_.
Another difference is the way changes are integrated. In
a workflow without shared repositories, only pull is used
for integration, while push in only used for publishing the
changes.
Wrong. push is a mirror of fetch and does not do _any_
integration. It is just a safe (because it insists on
fast-forward) propagation mechanism. Your integration still
happens with pull (actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
This is different if you work with a shared repository. Bob
checks out the shared branch foo to his local branch bar and
later he needs to push bar back to the shared branch foo. Bob
needs to push changes from his local branch bar to the branch
foo in the remote repository, a branch with a different name.
This need does not emerge when working with two publishing
repositories, as described above.
So you do "git push $remote bar:foo". If you do that regulary,
there are configuration mechanisms to help you reduce your
keyboard wear. What's the problem?
On Oct 31, 2007, at 10:31 PM, Junio C Hamano wrote:
Steffen Prohaska [off-list ref] writes:
quoted
quoted
You forgot a lot more important part. Pushing into publishing
repositories. And the discussion is about git-push command.
Exactly, here are two examples:
If you push only to publishing repositories that are read
only by others, you'll never encounter the problem that
10/10 tried to solve. The publishing repository is never
changed by others. You are the only one who pushes to this
repository. Therefore the remote never advances unexpectedly.
Wrong.
People can and do work from more than one private repositories
(I do). In a sense, that is sharing the repository with
oneself.
I do, too. But as long as I do not forget what I've done, the
branches do not advance _unexpectedly_. I am in full control.
I may do an emergency patch to fix breakage on 'maint' (and
'maint' only) from a location that is not my primary development
box and push the fix out. I fully expect that the push will
push out 'maint' and expect the other branches such as 'master'
on the remote side to stay the same, as I haven't touched
'master' on that box for quite a while and it is now stale. In
that situation, I _want_ the "git push" itself to report failure
to notify me that it did not push what _I_ asked it to push out,
so that I can be reminded that I'd better do "git push $remote
maint" the next time. In the meantime, even though it reports
a failure, 'master' on the remote side is _not_ updated, so the
behaviour is still _safe_.
You're right it is safe, but it may be confusing.
quoted
Another difference is the way changes are integrated. In
a workflow without shared repositories, only pull is used
for integration, while push in only used for publishing the
changes.
Wrong. push is a mirror of fetch and does not do _any_
integration. It is just a safe (because it insists on
fast-forward) propagation mechanism. Your integration still
happens with pull (actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
Right; but you can't push without doing the integration. If you
have new changes on the remote side you _must_ pull before
you can push. You're forced to do the integration immediately.
Your main objective was to push, but the shared workflow forces
you to do the integration _now_ (by using pull). In a pull-only
workflow, you can just push and defere the integration for later.
Some people claim fetch + rebase is superior to fetch + merge.
The only point I can see is that fetch + rebase gives a linear
history without loops, which is nicer to visualize. I recently
asked on the list if there are any benefits of fetch + rebase
over fetch + merge, besides a nicer visualization. I didn't
receive many interesting comments. One comment explained
that rebase can shift the merge conflict resolution from
the maintainer (merge) to the original author (rebase). But
this is not very interesting in a shared workflow, because
the author must resolve conflicts in any case before he can
push. It doesn't matter much if he uses merge or rebase to
do so.
I evaluated if teaching people fetch + rebase before teaching
fetch + merge is a good idea. Therefore I tested some scenarios
with people who are new to git. The result is that there are
too many situations where fetch + rebase might be confusing.
I abandoned my idea.
I decided that fetch + merge is _easier_. It works in all
situations, it's easier to explain, it's better supported
(automerge), it can be used to work on shared topic branches.
Definitely fetch + merge is the first workflow you should
learn. At the moment I'm not anymore interested in the fetch +
rebase approach.
quoted
This is different if you work with a shared repository. Bob
checks out the shared branch foo to his local branch bar and
later he needs to push bar back to the shared branch foo. Bob
needs to push changes from his local branch bar to the branch
foo in the remote repository, a branch with a different name.
This need does not emerge when working with two publishing
repositories, as described above.
So you do "git push $remote bar:foo". If you do that regulary,
there are configuration mechanisms to help you reduce your
keyboard wear. What's the problem?
Too complex and not flexible enough.
The configuration is in the remote section. Therefore I can
tell git what to do only on a per-branch basis. What do you
think about my recent proposal to add branch.$name.push?
And I want to avoid that people need to learn about the details
of the configuration mechanism on the first time they use git.
I am searching for a solution that just works for them. They
currently use CVS. I'll give them a detailed getting started
document for git. The workflow described should be as simple as
possible, but safe and reliable. No confusing error messages
should appear. Only a few commands should be needed to
contribute to a shared branch. The workflow described should
use git in a sane way that provides opportunities to use more
of its power later.
So here is what I'd like to have.
git clone ssh://server/git/project.git project
[ On Windows the hassel already starts because it actually is
git clone -n ssh://sever/git/project.git project
git config core.autocrlf true
And here's the next point. git config doesn't validate the
variable. It accepts _any_ variable. If you have a typo
you go without autocrlf. ... but this is a different story. ]
cd project
git checkout -b devel origin/devel
# work, commit, work, commit
git push # maybe git pull first, but git would tell you
The last command, git push, can already cause trouble. git
automatically created a local master and the remote master
may have advanced, so git push would complain with an error.
Currently the correct command would be
"git push origin devel".
An alternative scenario is that you want to start work that
will not be ready right away. So you start a topic branch
git checkout -b topic origin/devel
# work, commit, some time passes, work, commit
git pull # integrate changes from devel
# work, commit
git pull
git push # this one should push to origin/devel
In scenario three you planned to finish your work right away
but the problem turned out to be harder. Here, the following
would be nice
git checkout -b devel origin/devel
# work, commit, hmm... much harder ...
git branch -m devel dolater
# do something else
git checkout dolater
# finish work
git pull # integrate with other work on devel
git push # push back to shared branch
Another question is what to do with a local branch after
you finished work. We recently had the
"Re: best git practices, was Re: Git User's Survey 2007
unfinished summary continued" aka the 200-local-branches
discussion.
There were different suggestions what to do. A reasonable
suggestion was to delete the local branch after you're done.
This clearly distinguishes between remote branches (which are
mirrored as a remote tracking branch) and local branches. Local
branches are _your_ branches while the remote branches contain
the shared work. If you're done with your local work, delete
your local branch. So maybe you should do
git checkout origin/devel
git branch -d devel
Now you're on a detached branch that points to origin/work.
But how to do you get new changes from others? git pull would
not work and git fetch neither.
Independently of what the best practice is, leaving the local
work branch there shouldn't do any harm because I'm sure that
some devs will forget to clean up, independently of what I tell
them.
Steffen
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:45
Junio C Hamano wrote:
Steffen Prohaska [off-list ref] writes:
quoted
quoted
You forgot a lot more important part. Pushing into publishing
repositories. And the discussion is about git-push command.
Exactly, here are two examples:
If you push only to publishing repositories that are read
only by others, you'll never encounter the problem that
10/10 tried to solve. The publishing repository is never
changed by others. You are the only one who pushes to this
repository. Therefore the remote never advances unexpectedly.
Wrong.
People can and do work from more than one private repositories
(I do). In a sense, that is sharing the repository with
oneself.
I believe your troubles are alleviated a great deal by the fact
that you actually know when upstream has changes, and what those
changes are supposed to be. A communications breakdown with only
one person involved is sort of hard to imagine.
(actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
That's definitely true. The number of useless merge-commits we
have in our repos is annoying, and has twice made bisect a bit
troublesome for no good reason.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
On Nov 1, 2007, at 9:18 AM, Andreas Ericsson wrote:
Junio C Hamano wrote:
quoted
(actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
That's definitely true. The number of useless merge-commits we
have in our repos is annoying, and has twice made bisect a bit
troublesome for no good reason.
Can you describe a bit more what's "annoying" about them?
Is it the visualization? Or are there more problems; like
the trouble with bisect?
I'm trying to estimate if it's worth teaching _all_
developers rebase or if we should just live with the "useless"
merge-commits.
Steffen
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:45
Steffen Prohaska wrote:
On Oct 31, 2007, at 10:31 PM, Junio C Hamano wrote:
quoted
Steffen Prohaska [off-list ref] writes:
quoted
quoted
You forgot a lot more important part. Pushing into publishing
repositories. And the discussion is about git-push command.
Exactly, here are two examples:
If you push only to publishing repositories that are read
only by others, you'll never encounter the problem that
10/10 tried to solve. The publishing repository is never
changed by others. You are the only one who pushes to this
repository. Therefore the remote never advances unexpectedly.
Wrong.
People can and do work from more than one private repositories
(I do). In a sense, that is sharing the repository with
oneself.
I do, too. But as long as I do not forget what I've done, the
branches do not advance _unexpectedly_. I am in full control.
quoted
I may do an emergency patch to fix breakage on 'maint' (and
'maint' only) from a location that is not my primary development
box and push the fix out. I fully expect that the push will
push out 'maint' and expect the other branches such as 'master'
on the remote side to stay the same, as I haven't touched
'master' on that box for quite a while and it is now stale. In
that situation, I _want_ the "git push" itself to report failure
to notify me that it did not push what _I_ asked it to push out,
so that I can be reminded that I'd better do "git push $remote
maint" the next time. In the meantime, even though it reports
a failure, 'master' on the remote side is _not_ updated, so the
behaviour is still _safe_.
You're right it is safe, but it may be confusing.
quoted
quoted
Another difference is the way changes are integrated. In
a workflow without shared repositories, only pull is used
for integration, while push in only used for publishing the
changes.
Wrong. push is a mirror of fetch and does not do _any_
integration. It is just a safe (because it insists on
fast-forward) propagation mechanism. Your integration still
happens with pull (actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
Right; but you can't push without doing the integration. If you
have new changes on the remote side you _must_ pull before
you can push.
Yes, because otherwise you'd rewrite published history. That's not
a good thing.
You're forced to do the integration immediately.
Yes, but you get to choose how. Perhaps git-push should list more
options than just git-pull, such as the three commands required to
rebase the currently checked out branch onto its remote counterpart.
That would support more workflows.
Your main objective was to push, but the shared workflow forces
you to do the integration _now_ (by using pull). In a pull-only
workflow, you can just push and defere the integration for later.
No, you can also fetch + rebase.
Some people claim fetch + rebase is superior to fetch + merge.
The only point I can see is that fetch + rebase gives a linear
history without loops, which is nicer to visualize. I recently
asked on the list if there are any benefits of fetch + rebase
over fetch + merge, besides a nicer visualization.
It's easier to bisect. If git bisect lands you on a merge-commit,
you need to start a new bisect for each of the parents included
in the merge. Hopefully the nature of the merge gives a clue so
the user can make an educated guess as to which parent introduced
the bogus commit, but for an "evil octopus" (unusual) or if the
merge had conflicts which were resolved in a buggy way (not
exactly uncommon), it can be quite a hassle to get things right.
With a mostly linear history, this problem goes away.
I didn't
receive many interesting comments. One comment explained
that rebase can shift the merge conflict resolution from
the maintainer (merge) to the original author (rebase). But
this is not very interesting in a shared workflow, because
the author must resolve conflicts in any case before he can
push. It doesn't matter much if he uses merge or rebase to
do so.
It depends. When commit ordering doesn't matter the original
author can use "git rebase --skip" and then continue with the
rebase to get as much as possible out as quickly as possible.
I'm in the unfortunate position of having a boss that likes
to fiddle with help-texts in code when it's in alpha-testing.
Sometimes that causes conflicts but it's often not important
enough to spend 30 minutes figuring out how to resolve it
properly. I tend to just skip those patches and send them as
emails to our tech-writer instead, asking him to rephrase the
text to incorporate both changes, and then manually applying
the text to the end result.
I am searching for a solution that just works for them. They
currently use CVS. I'll give them a detailed getting started
document for git. The workflow described should be as simple as
possible, but safe and reliable.
If they're used to CVS and want to use more than one branch without
having to learn additional syntax, nothing can help, methinks.
Another question is what to do with a local branch after
you finished work. We recently had the
"Re: best git practices, was Re: Git User's Survey 2007
unfinished summary continued" aka the 200-local-branches
discussion.
We're at 224 branches now, having added 7 new repos.
There were different suggestions what to do. A reasonable
suggestion was to delete the local branch after you're done.
Except that it doesn't work unless you either detach the HEAD
(which prints a big fat ugly message) or give it -D to force
it, which I really, really don't recommend. We use git because
I'm pretty confident in its capabilities of never ever losing
anything. Using the seemingly harmless -D switch to git-branch
puts us at risk of wiping history quite without noticing.
This clearly distinguishes between remote branches (which are
mirrored as a remote tracking branch) and local branches. Local
branches are _your_ branches while the remote branches contain
the shared work. If you're done with your local work, delete
your local branch. So maybe you should do
git checkout origin/devel
Except that this gives a warning-esque message:
Note: moving to "origin/devel" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at deadbeef... Ma! Pa butchered all the cows!
To me, this indicates I've done something git thinks I shouldn't have.
Independently of what the best practice is, leaving the local
work branch there shouldn't do any harm because I'm sure that
some devs will forget to clean up, independently of what I tell
them.
I wholeheartedly agree with this one.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:45
Steffen Prohaska wrote:
On Nov 1, 2007, at 9:18 AM, Andreas Ericsson wrote:
quoted
Junio C Hamano wrote:
quoted
(actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
That's definitely true. The number of useless merge-commits we
have in our repos is annoying, and has twice made bisect a bit
troublesome for no good reason.
Can you describe a bit more what's "annoying" about them?
Is it the visualization? Or are there more problems; like
the trouble with bisect?
Visualization is a small nuissance. git-bisect troubles are more
worrisome. I've been in the seat where useless merges means git
bisect needs constant babysitting and constant manual handling.
It's no fun at all, so we're sticking with the fetch+rebase flow.
I'm trying to estimate if it's worth teaching _all_
developers rebase or if we should just live with the "useless"
merge-commits.
I'd say that depends on how valuable you find gitk, qgit and
git-bisect are. To me, I'd happily use any scm in the world,
so long as it has git-bisect. Otoh, I'm a lazy bastard and
love bisect so much that all our automated tests are focused
around "git bisect run". This means bugs in software released
to customers are few and far apart. When we get one reported,
we just create a new test that exposes it, fire up git-bisect
and then go to lunch. Quality costs, however. We pay that bill
by using a workflow that's perhaps more convoluted than
necessary.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
Steffen Prohaska wrote:
quoted
On Oct 31, 2007, at 10:31 PM, Junio C Hamano wrote:
quoted
Steffen Prohaska [off-list ref] writes:
quoted
Another difference is the way changes are integrated. In
a workflow without shared repositories, only pull is used
for integration, while push in only used for publishing the
changes.
Wrong. push is a mirror of fetch and does not do _any_
integration. It is just a safe (because it insists on
fast-forward) propagation mechanism. Your integration still
happens with pull (actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
Right; but you can't push without doing the integration. If you
have new changes on the remote side you _must_ pull before
you can push.
Yes, because otherwise you'd rewrite published history. That's not
a good thing.
quoted
You're forced to do the integration immediately.
Yes, but you get to choose how. Perhaps git-push should list more
options than just git-pull, such as the three commands required to
rebase the currently checked out branch onto its remote counterpart.
That would support more workflows.
I agree. Providing better hints would be good.
quoted
Your main objective was to push, but the shared workflow forces
you to do the integration _now_ (by using pull). In a pull-only
workflow, you can just push and defer the integration for later.
No, you can also fetch + rebase.
Right. My point was than one cannot defer the integration. It
must be addressed immediately.
quoted
Some people claim fetch + rebase is superior to fetch + merge.
The only point I can see is that fetch + rebase gives a linear
history without loops, which is nicer to visualize. I recently
asked on the list if there are any benefits of fetch + rebase
over fetch + merge, besides a nicer visualization.
It's easier to bisect. If git bisect lands you on a merge-commit,
you need to start a new bisect for each of the parents included
in the merge. Hopefully the nature of the merge gives a clue so
the user can make an educated guess as to which parent introduced
the bogus commit, but for an "evil octopus" (unusual) or if the
merge had conflicts which were resolved in a buggy way (not
exactly uncommon), it can be quite a hassle to get things right.
With a mostly linear history, this problem goes away.
This is really an interesting point. I did not start to use
git bisect regularly. But I certainly plan to do so in the future.
Couldn't bisect learn to better cope with non-linear history?
[...]
quoted
I am searching for a solution that just works for them. They
currently use CVS. I'll give them a detailed getting started
document for git. The workflow described should be as simple as
possible, but safe and reliable.
If they're used to CVS and want to use more than one branch without
having to learn additional syntax, nothing can help, methinks.
They will learn. But they must not get frustrated too early.
I also don't wont to see them lining up in front of my office.
BTW, what do you thing about the proposal to add branch.$name.push [1]?
[1] http://marc.info/?l=git&m=119384331712996&w=2
[...]
quoted
There were different suggestions what to do. A reasonable
suggestion was to delete the local branch after you're done.
Except that it doesn't work unless you either detach the HEAD
(which prints a big fat ugly message) or give it -D to force
it, which I really, really don't recommend. We use git because
I'm pretty confident in its capabilities of never ever losing
anything. Using the seemingly harmless -D switch to git-branch
puts us at risk of wiping history quite without noticing.
I don't like -D either. I liked the idea mentioned recently
to check -d against the remotes. If a remote tracking branch
has the history it should be considered fully merged.
Another idea may be to distinguish between detached head and
checkout of remote tracking branch. Maybe we could do some
useful things if get knew that the user is 'on a remote tracking
branch'. Committing could be forbidden. A suggestion would be
printed instead to use "git checkout -b something", which could act
as if the remote branch was mentioned on the command line.
Something like that would be needed before I'd seriously
suggest to delete local branches after you finished your work.
quoted
This clearly distinguishes between remote branches (which are
mirrored as a remote tracking branch) and local branches. Local
branches are _your_ branches while the remote branches contain
the shared work. If you're done with your local work, delete
your local branch. So maybe you should do
git checkout origin/devel
Except that this gives a warning-esque message:
Note: moving to "origin/devel" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at deadbeef... Ma! Pa butchered all the cows!
To me, this indicates I've done something git thinks I shouldn't have.
I agree. This could probably be suppressed if git handled remote
tracking branches a bit differently from other detached heads.
quoted
Independently of what the best practice is, leaving the local
work branch there shouldn't do any harm because I'm sure that
some devs will forget to clean up, independently of what I tell
them.
I wholeheartedly agree with this one.
So I think we need to resolve this first.
Do you already have post-checkout script that makes useful
suggestions. I remember you mentioned something like that
during the 200-local-branches discussion.
Steffen
El 31/10/2007, a las 22:31, Junio C Hamano escribió:
Wrong. push is a mirror of fetch and does not do _any_
integration. It is just a safe (because it insists on
fast-forward) propagation mechanism. Your integration still
happens with pull (actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
Of course, it's too late too change now, but it would be nice if the
mirror of "fetch" were "send". (I know it's been commented in the past
that the fact that "push" and "pull" aren't mirror operations has
surprised quite a few people.)
Cheers,
Wincent
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:46
Steffen Prohaska wrote:
On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
quoted
It's easier to bisect. If git bisect lands you on a merge-commit,
you need to start a new bisect for each of the parents included
in the merge. Hopefully the nature of the merge gives a clue so
the user can make an educated guess as to which parent introduced
the bogus commit, but for an "evil octopus" (unusual) or if the
merge had conflicts which were resolved in a buggy way (not
exactly uncommon), it can be quite a hassle to get things right.
With a mostly linear history, this problem goes away.
This is really an interesting point. I did not start to use
git bisect regularly. But I certainly plan to do so in the future.
Couldn't bisect learn to better cope with non-linear history?
Perhaps it could, but it's far from trivial. I started hacking on
a wrapper for git-bisect which would do just that, but gave up
rather quickly as the book-keeping required to remember each and
every parent-point tried just got out of hand, and it *still*
wouldn't run in full automatic. It broke down because I also
wanted merges on non-first-line parents to be delved into. If
that didn't happen, I wouldn't *know* the bisect would run fine
without me watching it, so then it was as useless as if I'd have
had to sit there the entire time anyway.
I'm not so sure about it. I rather liked the "don't warn if local is
strict subset of remote" thing though. I teach our devs to just
ignore that warning, but with the same leaden feeling in my stomach
that someone, sometime, is going to get bit by it. It's worked so
far though, perhaps because our update-hook contains a check meaning
I'm the only one allowed to do "git-push --force".
quoted
Except that it doesn't work unless you either detach the HEAD
(which prints a big fat ugly message) or give it -D to force
it, which I really, really don't recommend. We use git because
I'm pretty confident in its capabilities of never ever losing
anything. Using the seemingly harmless -D switch to git-branch
puts us at risk of wiping history quite without noticing.
I don't like -D either. I liked the idea mentioned recently
to check -d against the remotes. If a remote tracking branch
has the history it should be considered fully merged.
Yes. Since remote branches are considered when prune'ing anyway,
and the git-branch -d warning is there to make sure we don't
accidentally lose any tip pointers, it should be safe to use
*all* "named" refs when checking for git-branch -d's sake (that
is, everything under refs/{heads,remotes,tags}/**/*).
Another idea may be to distinguish between detached head and
checkout of remote tracking branch. Maybe we could do some
useful things if get knew that the user is 'on a remote tracking
branch'. Committing could be forbidden.
Committing nearly *has* to be forbidden.
A suggestion would be
printed instead to use "git checkout -b something", which could act
as if the remote branch was mentioned on the command line.
Something like that would be needed before I'd seriously
suggest to delete local branches after you finished your work.
Yup. I'll never suggest using "git branch -D" to my co-workers. Sooner
or later there'll be cries of anguish echoing throughout the office
when that happens ;-)
quoted
quoted
Independently of what the best practice is, leaving the local
work branch there shouldn't do any harm because I'm sure that
some devs will forget to clean up, independently of what I tell
them.
I wholeheartedly agree with this one.
So I think we need to resolve this first.
Do you already have post-checkout script that makes useful
suggestions. I remember you mentioned something like that
during the 200-local-branches discussion.
No. Junio suggested I'd implement it as a post-checkout hook, but it
would only save me one command and could cause confusion as diff
output would change depending on whether one has checked out the
one branch or another prior to running git diff, so I decided against
it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:46
Hi,
On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
Of course, it's too late too change now, but it would be nice if the
mirror of "fetch" were "send". (I know it's been commented in the past
that the fact that "push" and "pull" aren't mirror operations has
surprised quite a few people.)
Could you please just do
git config --global alias.send push
and be done with it?
Hth,
Dscho
On Nov 2, 2007, at 1:14 PM, Johannes Schindelin wrote:
Hi,
On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
quoted
Of course, it's too late too change now, but it would be nice if the
mirror of "fetch" were "send". (I know it's been commented in the
past
that the fact that "push" and "pull" aren't mirror operations has
surprised quite a few people.)
Could you please just do
git config --global alias.send push
and be done with it?
This would certainly be the easiest. But I think the following
is probably more in line with Wincent's comment:
Makefile builds git-send instead of git-push
git config --global alias.push send
[ wait some time ]
git config --unset alias.push
The comment was about how to avoid surprises for people that
are new to git, not how to let long-time users have an alias
for push.
The _only_ real solution I see right now, is to stop the
discussion and leave "git push" as is. I strongly believe that
the git community in its majority will refuse to rename push;
though I have no evidence for this.
Steffen
El 2/11/2007, a las 13:48, Steffen Prohaska escribió:
On Nov 2, 2007, at 1:14 PM, Johannes Schindelin wrote:
quoted
On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
quoted
Of course, it's too late too change now, but it would be nice if the
mirror of "fetch" were "send". (I know it's been commented in the
past
that the fact that "push" and "pull" aren't mirror operations has
surprised quite a few people.)
Could you please just do
git config --global alias.send push
and be done with it?
(snip)
The comment was about how to avoid surprises for people that
are new to git, not how to let long-time users have an alias
for push.
Exactly. I was talking about the *initial* surprise for new users, not
for people who already know the difference between push, pull and
fetch (99% of people reading this list already, myself included).
The _only_ real solution I see right now, is to stop the
discussion and leave "git push" as is. I strongly believe that
the git community in its majority will refuse to rename push;
though I have no evidence for this.
As I said above, "Of course, it's too late to change now"... I don't
think it will be renamed either.
Cheers,
Wincent
From: Tom Prince <hidden> Date: 2016-06-15 22:43:46
On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote:
Steffen Prohaska wrote:
quoted
On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
quoted
It's easier to bisect. If git bisect lands you on a merge-commit,
you need to start a new bisect for each of the parents included
in the merge. Hopefully the nature of the merge gives a clue so
the user can make an educated guess as to which parent introduced
the bogus commit, but for an "evil octopus" (unusual) or if the
merge had conflicts which were resolved in a buggy way (not
exactly uncommon), it can be quite a hassle to get things right.
With a mostly linear history, this problem goes away.
This is really an interesting point. I did not start to use
git bisect regularly. But I certainly plan to do so in the future.
Couldn't bisect learn to better cope with non-linear history?
Perhaps it could, but it's far from trivial. I started hacking on
a wrapper for git-bisect which would do just that, but gave up
rather quickly as the book-keeping required to remember each and
every parent-point tried just got out of hand, and it *still*
wouldn't run in full automatic. It broke down because I also
wanted merges on non-first-line parents to be delved into. If
that didn't happen, I wouldn't *know* the bisect would run fine
without me watching it, so then it was as useless as if I'd have
had to sit there the entire time anyway.
I haven't had occasion to use git-bisect much, but I was under the
impression that bisect could already handle merges, or any other shaped
history just fine.
If you test a merge and it is bad, git (eventually) picks a commit on one of
the branches. If that commit is good, then the merge-base is good, so that the
bug lies on some other branch. If that commit is bad, then the bug is on some
ancestor of the branch. Thus, no need for special book keeping.
Tom
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:46
Tom Prince wrote:
On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote:
quoted
Steffen Prohaska wrote:
quoted
On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
quoted
It's easier to bisect. If git bisect lands you on a merge-commit,
you need to start a new bisect for each of the parents included
in the merge. Hopefully the nature of the merge gives a clue so
the user can make an educated guess as to which parent introduced
the bogus commit, but for an "evil octopus" (unusual) or if the
merge had conflicts which were resolved in a buggy way (not
exactly uncommon), it can be quite a hassle to get things right.
With a mostly linear history, this problem goes away.
This is really an interesting point. I did not start to use
git bisect regularly. But I certainly plan to do so in the future.
Couldn't bisect learn to better cope with non-linear history?
Perhaps it could, but it's far from trivial. I started hacking on
a wrapper for git-bisect which would do just that, but gave up
rather quickly as the book-keeping required to remember each and
every parent-point tried just got out of hand, and it *still*
wouldn't run in full automatic. It broke down because I also
wanted merges on non-first-line parents to be delved into. If
that didn't happen, I wouldn't *know* the bisect would run fine
without me watching it, so then it was as useless as if I'd have
had to sit there the entire time anyway.
I haven't had occasion to use git-bisect much, but I was under the
impression that bisect could already handle merges, or any other shaped
history just fine.
It appears the code supports your statement. I started writing on my
hack-around about a year ago, and the merge-handling code got in with
1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007.
Perhaps I shouldn't be so paranoid about useless merges anymore then.
Hmm. I shall have to look into it. Perhaps Junio can clarify how it
works? The man-page was terribly silent about how git-bisect handles
merges.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
On Nov 2, 2007, at 2:52 PM, Andreas Ericsson wrote:
quoted
I haven't had occasion to use git-bisect much, but I was under the
impression that bisect could already handle merges, or any other
shaped
history just fine.
It appears the code supports your statement. I started writing on my
hack-around about a year ago, and the merge-handling code got in with
1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007.
Perhaps I shouldn't be so paranoid about useless merges anymore then.
Hmm. I shall have to look into it. Perhaps Junio can clarify how it
works? The man-page was terribly silent about how git-bisect handles
merges.
So eventually there's coming something good out of this thread,
without actually writing any code ;)
Steffen