* Re: git pull for update of netdev fails.
2006-09-20 15:54 ` Petr Baudis
@ 2006-09-20 16:02 ` Johannes Schindelin
2006-09-20 16:07 ` Petr Baudis
2006-09-20 16:05 ` Junio C Hamano
` (2 subsequent siblings)
3 siblings, 1 reply; 43+ messages in thread
From: Johannes Schindelin @ 2006-09-20 16:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
Hi,
On Wed, 20 Sep 2006, Petr Baudis wrote:
> Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> said that...
> > However, you can tell git that Jeff is being difficult by marking such
> > branches individually as being rebased.
>
> This is really a wrong way of describing the problem - I'd say that Git
> is being difficult here. The point is, the subsystem maintainers need to
> maintain stacks of patches and rebase against the main kernel branch
> regularily, and they want to still publish their current state. So it's
> not really any of them being strange or difficult, but Git being so
> because it has no seamless support for tracking those branches.
So, what exactly do you propose? I do not see any way to help this
problem, since you really throw away history. So, the
git-is-being-difficult has to be taken with a pound of salt here.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: git pull for update of netdev fails.
2006-09-20 16:02 ` Johannes Schindelin
@ 2006-09-20 16:07 ` Petr Baudis
2006-09-20 16:19 ` Linus Torvalds
0 siblings, 1 reply; 43+ messages in thread
From: Petr Baudis @ 2006-09-20 16:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
Hi,
Dear diary, on Wed, Sep 20, 2006 at 06:02:43PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Wed, 20 Sep 2006, Petr Baudis wrote:
>
> > Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter
> > where Linus Torvalds <torvalds@osdl.org> said that...
> > > However, you can tell git that Jeff is being difficult by marking such
> > > branches individually as being rebased.
> >
> > This is really a wrong way of describing the problem - I'd say that Git
> > is being difficult here. The point is, the subsystem maintainers need to
> > maintain stacks of patches and rebase against the main kernel branch
> > regularily, and they want to still publish their current state. So it's
> > not really any of them being strange or difficult, but Git being so
> > because it has no seamless support for tracking those branches.
>
> So, what exactly do you propose? I do not see any way to help this
> problem, since you really throw away history. So, the
> git-is-being-difficult has to be taken with a pound of salt here.
I personally don't think "throwing away" history is an issue. You can
print the old sha1 and it is still in the database so you can recover
it. And if you are really paranoid about it (in what scenario do you
actually care?), enable reflog and you will have the old sha1s recorded
there.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:07 ` Petr Baudis
@ 2006-09-20 16:19 ` Linus Torvalds
2006-09-20 16:26 ` Linus Torvalds
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Linus Torvalds @ 2006-09-20 16:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
On Wed, 20 Sep 2006, Petr Baudis wrote:
>
> I personally don't think "throwing away" history is an issue. You can
> print the old sha1 and it is still in the database so you can recover
> it.
No it isn't. Once you've lost the reference, you can't really depend on it
any more in the long run.
A lot of people do things like "git repack -a -d" by hand, and we've tried
to encourage people to do so in cron-jobs etc. We've even had patches
floating around that do it automatically after a pull.
In other words, once a ref is gone, you are easily going to loose the
history to it too. Also, regardless, you should be told about it, UNLESS
YOU HAVE EXPLICITLY STATED THAT YOU DON'T CARE ABOUT HISTORY!
That's a really important point. You can trivially say "I don't care".
It's literally one extra character. But it should be the _user_ that says
so, not the SCM.
The whole point of the SCM is to care.
Linus
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: git pull for update of netdev fails.
2006-09-20 16:19 ` Linus Torvalds
@ 2006-09-20 16:26 ` Linus Torvalds
2006-09-20 16:34 ` Shawn Pearce
2006-09-20 16:28 ` Shawn Pearce
2006-09-20 21:14 ` Johannes Schindelin
2 siblings, 1 reply; 43+ messages in thread
From: Linus Torvalds @ 2006-09-20 16:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
On Wed, 20 Sep 2006, Linus Torvalds wrote:
>
> That's a really important point. You can trivially say "I don't care".
> It's literally one extra character. But it should be the _user_ that says
> so, not the SCM.
>
> The whole point of the SCM is to care.
Btw, the "+" also protects you from local errors.
Let's say that you've committed some work of your own onto a branch that
you happen to follow. Guess what? By default, git refuses to throw your
hard work away.
This is not just a random thing. It is in fact one of the very core issues
of having multiple people work together on the same remote repo. We don't
do it very much (because it's often easier for everybody to have their
own), but the "CVS workflow" with one common repository is another example
why WE MUST NOT JUST RESET THE HEADS!
Think about it. You and somebody else works on a common branch, using a
common source repo. When you "fetch", you want to get all the work that
the other person has done. But you sure as hell don't want that work to
overwrite your own work.
So what does git do? It notices if you have a local commit on that shared
branch (because it no longer fast-forwards to the other end), and it tells
you exactly that: it says that branch so-and-so doesn't fast-forward, and
refuses to overwrite it.
What would you do? You should in that case switch to the offending branch,
AND DO A MERGE of your work and the work you shared with another person,
and then push out the result.
So the _last_ thing you want to happen is for your work to be silently
just overwritten.
Trust me, git does the right thing here. No ifs, buts or maybes about it.
Linus
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:26 ` Linus Torvalds
@ 2006-09-20 16:34 ` Shawn Pearce
2006-09-20 16:49 ` Linus Torvalds
2006-09-20 21:23 ` Johannes Schindelin
0 siblings, 2 replies; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 16:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Johannes Schindelin, git
Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 20 Sep 2006, Linus Torvalds wrote:
> >
> > That's a really important point. You can trivially say "I don't care".
> > It's literally one extra character. But it should be the _user_ that says
> > so, not the SCM.
> >
> > The whole point of the SCM is to care.
>
> Btw, the "+" also protects you from local errors.
>
> Let's say that you've committed some work of your own onto a branch that
> you happen to follow. Guess what? By default, git refuses to throw your
> hard work away.
>
> This is not just a random thing. It is in fact one of the very core issues
> of having multiple people work together on the same remote repo. We don't
> do it very much (because it's often easier for everybody to have their
> own), but the "CVS workflow" with one common repository is another example
> why WE MUST NOT JUST RESET THE HEADS!
BTW `git push --force` works just great to reset the remote head.
I worked on a project not to long ago in which a user tried `git
push`, received a "not a fast-forward" error, didn't know what it
meant, tried `git push --force`, found that worked, and proceeded
to force every push he did from then on. To much gnashing of teeth
from everyone else.
Of course an update hook finally took care of the problem, but having
non fast-forward pushs be permitted on a shared, bare repository
by default is interesting to say the least. :-)
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:34 ` Shawn Pearce
@ 2006-09-20 16:49 ` Linus Torvalds
2006-09-20 17:10 ` Shawn Pearce
2006-09-20 21:23 ` Johannes Schindelin
1 sibling, 1 reply; 43+ messages in thread
From: Linus Torvalds @ 2006-09-20 16:49 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Petr Baudis, Johannes Schindelin, git
On Wed, 20 Sep 2006, Shawn Pearce wrote:
> >
> > This is not just a random thing. It is in fact one of the very core issues
> > of having multiple people work together on the same remote repo. We don't
> > do it very much (because it's often easier for everybody to have their
> > own), but the "CVS workflow" with one common repository is another example
> > why WE MUST NOT JUST RESET THE HEADS!
>
> BTW `git push --force` works just great to reset the remote head.
Yes. That's why "--force" exists - it's a way of saying "the other end is
wrong, and I really do want to force this update".
> I worked on a project not to long ago in which a user tried `git
> push`, received a "not a fast-forward" error, didn't know what it
> meant, tried `git push --force`, found that worked, and proceeded
> to force every push he did from then on. To much gnashing of teeth
> from everyone else.
Ouch. That implies that we made it a bit too easy to force things, or that
we have an insufficiently clear error message.
I think the current error message is fairly good: it says
"remote '%s' is not a strict subset of local ref '%s'. maybe you
are not up-to-date and need to pull first?"
which should be clear enough, but I'm hoping this was a long time ago when
we weren't as clear (we added the "maybe you're not up-to-date .."
language later)
> Of course an update hook finally took care of the problem, but having
> non fast-forward pushs be permitted on a shared, bare repository
> by default is interesting to say the least. :-)
Yeah, well, it's not permitted "by default", but obviously "--force" ends
up being a client-side decision, so with clueless clients, the default
behaviour may not be enough to save you.
Linus
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:49 ` Linus Torvalds
@ 2006-09-20 17:10 ` Shawn Pearce
0 siblings, 0 replies; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 17:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Johannes Schindelin, git
Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
> > I worked on a project not to long ago in which a user tried `git
> > push`, received a "not a fast-forward" error, didn't know what it
> > meant, tried `git push --force`, found that worked, and proceeded
> > to force every push he did from then on. To much gnashing of teeth
> > from everyone else.
>
> Ouch. That implies that we made it a bit too easy to force things, or that
> we have an insufficiently clear error message.
I've been lucky that I've only run into two people in my life that
when faced with an error message they don't understand immediately
try adding "-f" and "--force" to the command line until something
happens. Its entertaining to read their terminal scrollback and
see what they did in response to errors; its less so when they've
done mildy destructive things that you now must cleanup.
Sometimes I wonder if they've managed to reformat their root
filesystem while they had it mounted. Never asked. Not sure I
want to hear the answer.
> I think the current error message is fairly good: it says
>
> "remote '%s' is not a strict subset of local ref '%s'. maybe you
> are not up-to-date and need to pull first?"
>
> which should be clear enough, but I'm hoping this was a long time ago when
> we weren't as clear (we added the "maybe you're not up-to-date .."
> language later)
Yes; this problem was back with Git 1.2 so the newer language is
much better and should help new users better.
> > Of course an update hook finally took care of the problem, but having
> > non fast-forward pushs be permitted on a shared, bare repository
> > by default is interesting to say the least. :-)
>
> Yeah, well, it's not permitted "by default", but obviously "--force" ends
> up being a client-side decision, so with clueless clients, the default
> behaviour may not be enough to save you.
I'm wondering if maybe git-receive-pack should deny forcing an
update in a shared repository unless there's either an update hook
that its going to run (which would get to vote yea or neigh) or
there's a configuration setting enabled which isn't set by default.
I'd think most users of a shared repository wouldn't want to allow
forcing an update except in some very special cases. For those
they could install an update hook or just push a new temporary
branch name and then use git-update-ref or git-branch directly on
the remote repository.
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:34 ` Shawn Pearce
2006-09-20 16:49 ` Linus Torvalds
@ 2006-09-20 21:23 ` Johannes Schindelin
2006-09-20 21:27 ` Shawn Pearce
1 sibling, 1 reply; 43+ messages in thread
From: Johannes Schindelin @ 2006-09-20 21:23 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Hi,
On Wed, 20 Sep 2006, Shawn Pearce wrote:
> Of course an update hook finally took care of the problem, but having
> non fast-forward pushs be permitted on a shared, bare repository
> by default is interesting to say the least. :-)
Unfortunately, it is send-pack making the decision on the client side, not
receive-pack on the server side, the latter of which knows if the server
side is shared or not.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:23 ` Johannes Schindelin
@ 2006-09-20 21:27 ` Shawn Pearce
2006-09-20 21:37 ` Johannes Schindelin
0 siblings, 1 reply; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 21:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
>
> > Of course an update hook finally took care of the problem, but having
> > non fast-forward pushs be permitted on a shared, bare repository
> > by default is interesting to say the least. :-)
>
> Unfortunately, it is send-pack making the decision on the client side, not
> receive-pack on the server side, the latter of which knows if the server
> side is shared or not.
Huh?
The server side update hook is given the old and new value of
the ref by receive-pack; if it exists with a non-zero status the
update fails.
The server side could also check if the current value in the ref
(if it exists) is contained within the new value of the ref. Yes,
I know it doesn't today, but the point is it could. And I was
saying maybe it should when there is no update hook present.
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:27 ` Shawn Pearce
@ 2006-09-20 21:37 ` Johannes Schindelin
2006-09-20 21:42 ` Junio C Hamano
2006-09-20 21:49 ` Shawn Pearce
0 siblings, 2 replies; 43+ messages in thread
From: Johannes Schindelin @ 2006-09-20 21:37 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Hi,
On Wed, 20 Sep 2006, Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 20 Sep 2006, Shawn Pearce wrote:
> >
> > > Of course an update hook finally took care of the problem, but having
> > > non fast-forward pushs be permitted on a shared, bare repository
> > > by default is interesting to say the least. :-)
> >
> > Unfortunately, it is send-pack making the decision on the client side, not
> > receive-pack on the server side, the latter of which knows if the server
> > side is shared or not.
>
> Huh?
>
> The server side update hook is given the old and new value of
> the ref by receive-pack; if it exists with a non-zero status the
> update fails.
>
> The server side could also check if the current value in the ref
> (if it exists) is contained within the new value of the ref. Yes,
> I know it doesn't today, but the point is it could. And I was
> saying maybe it should when there is no update hook present.
The point being that this check is not necessarily inexpensive. But you
are right, we could introduce this as a security measure. But is it really
intuitive to skip this test when an update hook is added?
I'd rather set another config variable with --shared, which tells git to
refuse receiving non-fast-forwards. This could be a sensible setting in
other setups than shared ones after all. Thoughts?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:37 ` Johannes Schindelin
@ 2006-09-20 21:42 ` Junio C Hamano
2006-09-20 21:53 ` Johannes Schindelin
2006-09-20 21:53 ` Shawn Pearce
2006-09-20 21:49 ` Shawn Pearce
1 sibling, 2 replies; 43+ messages in thread
From: Junio C Hamano @ 2006-09-20 21:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Shawn Pearce
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I'd rather set another config variable with --shared, which tells git to
> refuse receiving non-fast-forwards. This could be a sensible setting in
> other setups than shared ones after all. Thoughts?
If this option is meant to forbid fixing up an screw-up by doing
"git-push --force", I do not quite like it.
It sounds as if arguing that "rm -fr" is dangerous so presence
of -f and -r at the same time should imply -i option. I think
the right answer is not making -i implied, but train the user to
understand what -fr means before using it.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:42 ` Junio C Hamano
@ 2006-09-20 21:53 ` Johannes Schindelin
2006-09-20 21:53 ` Shawn Pearce
1 sibling, 0 replies; 43+ messages in thread
From: Johannes Schindelin @ 2006-09-20 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
Hi,
On Wed, 20 Sep 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I'd rather set another config variable with --shared, which tells git to
> > refuse receiving non-fast-forwards. This could be a sensible setting in
> > other setups than shared ones after all. Thoughts?
>
> If this option is meant to forbid fixing up an screw-up by doing
> "git-push --force", I do not quite like it.
>
> It sounds as if arguing that "rm -fr" is dangerous so presence
> of -f and -r at the same time should imply -i option. I think
> the right answer is not making -i implied, but train the user to
> understand what -fr means before using it.
I think it is more like being nice, and disallowing "rm -rf" via FTP,
forcing the user to do it locally.
In a shared repository I really, really, I mean: really, do not want to
mess a branch up that others pull from. And if I have to fix something, I
_can_ do it locally. (Plus the hassle reminds me of giving the pullers a
heads-up.)
Ciao,
Dscho
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:42 ` Junio C Hamano
2006-09-20 21:53 ` Johannes Schindelin
@ 2006-09-20 21:53 ` Shawn Pearce
1 sibling, 0 replies; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
Junio C Hamano <junkio@cox.net> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I'd rather set another config variable with --shared, which tells git to
> > refuse receiving non-fast-forwards. This could be a sensible setting in
> > other setups than shared ones after all. Thoughts?
>
> If this option is meant to forbid fixing up an screw-up by doing
> "git-push --force", I do not quite like it.
Yes, it is meant for stopping exactly that.
As the repository owner with direct access to the repository I
don't want anyone to be able to use --force to reset a branch.
If a branch reset needs to happen I want to do it directly on
the repository. Its a rather destructive operation, as we have
been saying. I don't want a user slamming in "--force" just because.
On the other hand you can also configure the option to allow
`git push --force` and craft a smart update hook which looks at
who is doing the push and if that is permissible to the ref in
question; exit'ing non-zero if not.
Basically I don't see why an update hook should be necessary to
disallow all non-fast forward pushes.
> It sounds as if arguing that "rm -fr" is dangerous so presence
> of -f and -r at the same time should imply -i option. I think
> the right answer is not making -i implied, but train the user to
> understand what -fr means before using it.
Some people cannot be trained. No matter how hard you may try.
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:37 ` Johannes Schindelin
2006-09-20 21:42 ` Junio C Hamano
@ 2006-09-20 21:49 ` Shawn Pearce
1 sibling, 0 replies; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 21:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
> > The server side could also check if the current value in the ref
> > (if it exists) is contained within the new value of the ref. Yes,
> > I know it doesn't today, but the point is it could. And I was
> > saying maybe it should when there is no update hook present.
>
> The point being that this check is not necessarily inexpensive.
But its not _that_ expensive. If the option is set to refuse
non-fast forwards then you take the hit and do the check; if its
set to allow them then you can bypass the check entirely and let
the client direct it (like it does today). Speed vs. safety.
I currently use "git rev-list $2..$1" in my update hooks to make sure
the update is strictly a fast-foward type update for all branches.
Enabling this option and having the check run in receive-pack would
be faster than what I'm doing now (one less fork).
> But you
> are right, we could introduce this as a security measure. But is it really
> intuitive to skip this test when an update hook is added?
Now that you say it, no. These two things (update hook and non-fast
forward update) are unrelated. If the update hook wants to make
the decision on a per branch basis then the option to allow a
non-fast forward push must be enabled in the config file.
> I'd rather set another config variable with --shared, which tells git to
> refuse receiving non-fast-forwards. This could be a sensible setting in
> other setups than shared ones after all. Thoughts?
Agree completely.
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:19 ` Linus Torvalds
2006-09-20 16:26 ` Linus Torvalds
@ 2006-09-20 16:28 ` Shawn Pearce
2006-09-20 16:38 ` Linus Torvalds
2006-09-20 21:14 ` Johannes Schindelin
2 siblings, 1 reply; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 16:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Johannes Schindelin, git
Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 20 Sep 2006, Petr Baudis wrote:
> >
> > I personally don't think "throwing away" history is an issue. You can
> > print the old sha1 and it is still in the database so you can recover
> > it.
>
> No it isn't. Once you've lost the reference, you can't really depend on it
> any more in the long run.
>
> A lot of people do things like "git repack -a -d" by hand, and we've tried
> to encourage people to do so in cron-jobs etc. We've even had patches
> floating around that do it automatically after a pull.
Ouch. That's really bad.
I knew it but didn't realize it until just now.
git repack -a -d
git branch -D foo
git repack -a -d
and *poof* no foo. Even if you somehow have its SHA1 and haven't
used `git prune` you still have just pruned the thing away and
can't look it up anymore.
git branch -D is just the obvious way of doing it. git rebase is
slightly less obvious for some people (perhaps more so for others).
git fetch with a '+' in a Pull: line is even less obvious, especially
if you have reflog enabled for exactly that reason.
So we've managed to encourage people to run prune without actually
running prune. Should we just integrate prune and repack -a -d with
the 'rm -rf /' command? Perhaps a kernel module at the VFS layer
would do the trick? I hear we have some kernel folks nearby. :-)
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:28 ` Shawn Pearce
@ 2006-09-20 16:38 ` Linus Torvalds
0 siblings, 0 replies; 43+ messages in thread
From: Linus Torvalds @ 2006-09-20 16:38 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Petr Baudis, Johannes Schindelin, git
On Wed, 20 Sep 2006, Shawn Pearce wrote:
> >
> > A lot of people do things like "git repack -a -d" by hand, and we've tried
> > to encourage people to do so in cron-jobs etc. We've even had patches
> > floating around that do it automatically after a pull.
>
> Ouch. That's really bad.
Well, what did you think the "-d" stood for?
It stands for "delete old packs".
There are exactly two operations that delete git objects: "git prune" and
"git repack -d". Nothing else should ever do it, but those two definitely
do. They're designed to.
I wouldn't call it "really bad" - it's part of the design. It's only bad
if you didn't realize what "-d" means.
> I knew it but didn't realize it until just now.
>
> git repack -a -d
> git branch -D foo
> git repack -a -d
>
> and *poof* no foo.
Exactly.
I thought people realized this, but apparently sometimes it's just an
intellectual understanding of what something does, without realizing what
that thing actually _means_ in a deeper way.
Linus
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:19 ` Linus Torvalds
2006-09-20 16:26 ` Linus Torvalds
2006-09-20 16:28 ` Shawn Pearce
@ 2006-09-20 21:14 ` Johannes Schindelin
2006-09-20 21:21 ` Shawn Pearce
` (2 more replies)
2 siblings, 3 replies; 43+ messages in thread
From: Johannes Schindelin @ 2006-09-20 21:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
Hi,
On Wed, 20 Sep 2006, Linus Torvalds wrote:
> On Wed, 20 Sep 2006, Petr Baudis wrote:
> >
> > I personally don't think "throwing away" history is an issue. You can
> > print the old sha1 and it is still in the database so you can recover
> > it.
>
> No it isn't. Once you've lost the reference, you can't really depend on it
> any more in the long run.
Exactly. And to add to that: you can lose the reference just by being not
fast enough. Example:
Some time ago, Junio was playing with colour in the output of git. He was
doing so in some branch he pulled into 'pu'. A few days later, he dropped
it. Now, I was lucky enough to have fetched pu within the short time span
where colour was part of 'pu', and some days (or weeks, don't remember)
later, I found some more time to play with the thing again, and
eventually submitted a patch reintroducing the colour thing.
So, you can lose things you actually never had!
Another, even more serious problems with rebasing: You can introduce a bug
by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
but the sum of your patches, and the patches you are rebasing on, is
buggy. And there is _no_ way to bisect this, since the "good" version can
be gone for good.
These two problems, combined with my love of history, make me never use
rebased branches myself, especially since I basically use git for projects
which I work on alone, just to synchronise between different sites.
As for the problem git-rebase tries to solve: you can get a clean branch
by cherry-picking what you have into a temporary branch, for the sole
purpose of being history clean.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: git pull for update of netdev fails.
2006-09-20 21:14 ` Johannes Schindelin
@ 2006-09-20 21:21 ` Shawn Pearce
2006-09-20 21:27 ` Johannes Schindelin
2006-09-20 22:34 ` Jakub Narebski
2006-09-23 3:44 ` Petr Baudis
2 siblings, 1 reply; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 21:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Petr Baudis, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Another, even more serious problems with rebasing: You can introduce a bug
> by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> but the sum of your patches, and the patches you are rebasing on, is
> buggy. And there is _no_ way to bisect this, since the "good" version can
> be gone for good.
True, however one would hope that you tested the commit before you
rebased it and found it to working. And bisect should point at the
new version of that commit as the break. And then you can debug
it there.
I've seen this happen very rarely, and usually its an initialization
or calling order type of bug and its usually has more to do with
other changes in the branch you are rebasing onto that aren't at the
side your patch affects.
Yes its something annoying to track down but certainly easy enough
with bisect, especially if you have relatively fine-grained commits
and a reasonably good test suite.
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:21 ` Shawn Pearce
@ 2006-09-20 21:27 ` Johannes Schindelin
2006-09-20 21:40 ` Shawn Pearce
0 siblings, 1 reply; 43+ messages in thread
From: Johannes Schindelin @ 2006-09-20 21:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Hi,
On Wed, 20 Sep 2006, Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Another, even more serious problems with rebasing: You can introduce a bug
> > by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> > but the sum of your patches, and the patches you are rebasing on, is
> > buggy. And there is _no_ way to bisect this, since the "good" version can
> > be gone for good.
>
> True, however one would hope that you tested the commit before you
> rebased it and found it to working. And bisect should point at the
> new version of that commit as the break. And then you can debug
> it there.
You misunderstood me. You can _introduce_ a bug by rebasing. _After_
testing that everything is fine. You can even test the rebased branch and
miss the bug, since your original tests were more thorough.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:27 ` Johannes Schindelin
@ 2006-09-20 21:40 ` Shawn Pearce
0 siblings, 0 replies; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 21:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Another, even more serious problems with rebasing: You can introduce a bug
> > > by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> > > but the sum of your patches, and the patches you are rebasing on, is
> > > buggy. And there is _no_ way to bisect this, since the "good" version can
> > > be gone for good.
> >
> > True, however one would hope that you tested the commit before you
> > rebased it and found it to working. And bisect should point at the
> > new version of that commit as the break. And then you can debug
> > it there.
>
> You misunderstood me. You can _introduce_ a bug by rebasing. _After_
> testing that everything is fine. You can even test the rebased branch and
> miss the bug, since your original tests were more thorough.
Why were your original tests more thorough and your rebased testing
was less so? Hmm? Perhaps the test suite needs to be extended as
part of the rebased commit(s).
Of course a rebase-introduced bug could also be in the test suite,
such that you miss the true bug. I've had bugs in the test suite
mask real bug, but never a bug both in the feature and in the test
due to a rebase or mad merge. I guess I've just been lucky there.
When rebasing and even when doing a non-fast forward merge one
needs to keep in mind that your code is being edited on your behalf.
Not much different then if you open it in your favorite editor and
whack away at a keyboard for a while. Sure these auto-edits work
most of the time, on their own and without user intervention, but
every once in while things get messed up. Heck, I've seen editors
mess up source files such that they won't compile anymore.
So moral of the story is you probably should be testing even after
rebasing or cherry picking, and the testing shouldn't be any less
extensive than before you did the rebase/cherry-pick. Which is one
reason why automated test suites can be useful, despite the risks
they also bring...
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:14 ` Johannes Schindelin
2006-09-20 21:21 ` Shawn Pearce
@ 2006-09-20 22:34 ` Jakub Narebski
2006-09-23 3:44 ` Petr Baudis
2 siblings, 0 replies; 43+ messages in thread
From: Jakub Narebski @ 2006-09-20 22:34 UTC (permalink / raw)
To: git
Johannes Schindelin wrote:
> Another, even more serious problems with rebasing: You can introduce a bug
> by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> but the sum of your patches, and the patches you are rebasing on, is
> buggy. And there is _no_ way to bisect this, since the "good" version can
> be gone for good.
Well, you can always tag tip of branch before rebasing, and remove the tag
when rebased branch is tested.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 21:14 ` Johannes Schindelin
2006-09-20 21:21 ` Shawn Pearce
2006-09-20 22:34 ` Jakub Narebski
@ 2006-09-23 3:44 ` Petr Baudis
2006-09-23 4:00 ` Shawn Pearce
2006-09-23 13:10 ` Catalin Marinas
2 siblings, 2 replies; 43+ messages in thread
From: Petr Baudis @ 2006-09-23 3:44 UTC (permalink / raw)
To: Johannes Schindelin, catalin.marinas; +Cc: Linus Torvalds, git
Dear diary, on Wed, Sep 20, 2006 at 11:14:25PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> Another, even more serious problems with rebasing: You can introduce a bug
> by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> but the sum of your patches, and the patches you are rebasing on, is
> buggy. And there is _no_ way to bisect this, since the "good" version can
> be gone for good.
Yes, I agree that this really is a problem, but that's a fundamental
limitation. At least for StGIT-maintained floating branches the latest
bleeding edge StGIT could fix that. (Except that the problem outlined by
Linus is present here as well, first prune will wipe your older patch
versions and your patch log will be useless - Catalin? Can we store the
older patch versions references in something like
.git/refs/patches-old/?) And except that it does that only for you -
there should be a way to conveniently mirror (clone+pull) the patch
stack setup.
> As for the problem git-rebase tries to solve: you can get a clean branch
> by cherry-picking what you have into a temporary branch, for the sole
> purpose of being history clean.
That's not really a reliable option because after getting your patches
through Christopher Hellwig you _will_ need to go back and poke some
patches in that history.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: git pull for update of netdev fails.
2006-09-23 3:44 ` Petr Baudis
@ 2006-09-23 4:00 ` Shawn Pearce
2006-09-23 4:09 ` Petr Baudis
2006-09-23 13:10 ` Catalin Marinas
1 sibling, 1 reply; 43+ messages in thread
From: Shawn Pearce @ 2006-09-23 4:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, catalin.marinas, Linus Torvalds, git
Petr Baudis <pasky@suse.cz> wrote:
> Yes, I agree that this really is a problem, but that's a fundamental
> limitation. At least for StGIT-maintained floating branches the latest
> bleeding edge StGIT could fix that. (Except that the problem outlined by
> Linus is present here as well, first prune will wipe your older patch
> versions and your patch log will be useless - Catalin? Can we store the
> older patch versions references in something like
> .git/refs/patches-old/?) And except that it does that only for you -
> there should be a way to conveniently mirror (clone+pull) the patch
> stack setup.
Why not change reflog to store the last n values or the last n days
(obtained from .git/config file) as refs under refs/prior-heads ?
I can see the same concept of ref history being useful even for
core git-rebase and doing it this way would also give it to StGIT
without Catalin needing to change code.
But it doesn't help git bisect.
Of course a looooong time ago when I first implemented reflog support
this was suggested but not implemented at the time due to the high
cost per ref. Now that we have Linus' packed refs available this
may not be nearly as much of a problem.
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-23 4:00 ` Shawn Pearce
@ 2006-09-23 4:09 ` Petr Baudis
2006-09-23 13:15 ` Catalin Marinas
0 siblings, 1 reply; 43+ messages in thread
From: Petr Baudis @ 2006-09-23 4:09 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Johannes Schindelin, catalin.marinas, Linus Torvalds, git
Dear diary, on Sat, Sep 23, 2006 at 06:00:35AM CEST, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> I can see the same concept of ref history being useful even for
> core git-rebase and doing it this way would also give it to StGIT
> without Catalin needing to change code.
In my StGIT tree, I don't want to have arbitrary N-days cutoff point,
I want all the patches history preserved at least as long as I carry
the patch, because it's just as valuable as the "regular" project
history to me.
> But it doesn't help git bisect.
It's not really all that clear how should bisect work in case of
multi-dimensional history. To do it sensibly, I guess you would have to
have another command like "stg commitseries" which declares "right now I
have the series (patches, their applied/unapplied state and their
ordering) in a clearly defined state" and then bisect between those.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: git pull for update of netdev fails.
2006-09-23 4:09 ` Petr Baudis
@ 2006-09-23 13:15 ` Catalin Marinas
0 siblings, 0 replies; 43+ messages in thread
From: Catalin Marinas @ 2006-09-23 13:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: Shawn Pearce, Johannes Schindelin, Linus Torvalds, git
On 23/09/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sat, Sep 23, 2006 at 06:00:35AM CEST, I got a letter
> where Shawn Pearce <spearce@spearce.org> said that...
> > I can see the same concept of ref history being useful even for
> > core git-rebase and doing it this way would also give it to StGIT
> > without Catalin needing to change code.
>
> In my StGIT tree, I don't want to have arbitrary N-days cutoff point,
> I want all the patches history preserved at least as long as I carry
> the patch, because it's just as valuable as the "regular" project
> history to me.
That's how it currently works (the top of the log is in
refs/patches/<branch>/<patch>.log). I gave up the idea of using
reflogs for patch history.
--
Catalin
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-23 3:44 ` Petr Baudis
2006-09-23 4:00 ` Shawn Pearce
@ 2006-09-23 13:10 ` Catalin Marinas
2006-09-24 20:54 ` Petr Baudis
1 sibling, 1 reply; 43+ messages in thread
From: Catalin Marinas @ 2006-09-23 13:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Linus Torvalds, git
Petr,
(I'm slow at replying and even slower at implementing anything over
the next 2-3 weeks - paternity leave :-))
On 23/09/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Sep 20, 2006 at 11:14:25PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > Another, even more serious problems with rebasing: You can introduce a bug
> > by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> > but the sum of your patches, and the patches you are rebasing on, is
> > buggy. And there is _no_ way to bisect this, since the "good" version can
> > be gone for good.
>
> Yes, I agree that this really is a problem, but that's a fundamental
> limitation. At least for StGIT-maintained floating branches the latest
> bleeding edge StGIT could fix that. (Except that the problem outlined by
> Linus is present here as well, first prune will wipe your older patch
> versions and your patch log will be useless - Catalin? Can we store the
> older patch versions references in something like
> .git/refs/patches-old/?) And except that it does that only for you -
> there should be a way to conveniently mirror (clone+pull) the patch
> stack setup.
I wasn't following this thread (well, any thread in the last days) but
the current patch history implementation in StGIT is prune-safe as it
generates additional commits to keep the history. If you undo an
operation (push, refresh), the undo will be recorded in the patch
history (that's really immutable). However, deleting a patch would
delete the corresponding history log as well.
--
Catalin
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-23 13:10 ` Catalin Marinas
@ 2006-09-24 20:54 ` Petr Baudis
2006-09-25 12:47 ` Catalin Marinas
0 siblings, 1 reply; 43+ messages in thread
From: Petr Baudis @ 2006-09-24 20:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Johannes Schindelin, Linus Torvalds, git
Dear diary, on Sat, Sep 23, 2006 at 03:10:17PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> said that...
> (I'm slow at replying and even slower at implementing anything over
> the next 2-3 weeks - paternity leave :-))
Congratulations! :-)
> I wasn't following this thread (well, any thread in the last days) but
> the current patch history implementation in StGIT is prune-safe as it
> generates additional commits to keep the history. If you undo an
> operation (push, refresh), the undo will be recorded in the patch
> history (that's really immutable)
It does not directly reference the history in the additional commits
though, it just mentions the sha1 in the log message - that is not
prune-safe:
$ cg-log -r patches/master/configchanges.log
...pick one at random...
commit 4e1ad4b1bfb9488636f1a43b3f3d4b8c3b4b2927
tree 4ba8253dff8190e75ad0f46deaef54747c4ad76d
parent 3d5f3a87134a056a52dc21bcc4b1c64a4eef9443
author pasky <pasky@rover.(none)> Tue, 19 Sep 2006 16:47:42 +0200
committer pasky <pasky@rover.(none)> Tue, 19 Sep 2006 16:47:42 +0200
* Makefile:
refresh 4852cc3fe638b332f4106b31a7abfafb2c6c3dfc
$ git-fsck-objects --unreachable | grep
4852cc3fe638b332f4106b31a7abfafb2c6c3dfc
unreachable commit 4852cc3fe638b332f4106b31a7abfafb2c6c3dfc
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: git pull for update of netdev fails.
2006-09-24 20:54 ` Petr Baudis
@ 2006-09-25 12:47 ` Catalin Marinas
0 siblings, 0 replies; 43+ messages in thread
From: Catalin Marinas @ 2006-09-25 12:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Linus Torvalds, git
On 24/09/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sat, Sep 23, 2006 at 03:10:17PM CEST, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> said that...
> > I wasn't following this thread (well, any thread in the last days) but
> > the current patch history implementation in StGIT is prune-safe as it
> > generates additional commits to keep the history. If you undo an
> > operation (push, refresh), the undo will be recorded in the patch
> > history (that's really immutable)
>
> It does not directly reference the history in the additional commits
> though, it just mentions the sha1 in the log message - that is not
> prune-safe:
Yes, indeed (I'm still tired :-)). The patch changes are safe and one
could probably generate the patch from them but it's a bit more
complicated. The quick solution is to add another parent to the
changelog commit so that it points to the patch. However, this
wouldn't look as nice with gitk as it sees them as merges and doesn't
display the diff (is there an option I missed?).
--
Catalin
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 15:54 ` Petr Baudis
2006-09-20 16:02 ` Johannes Schindelin
@ 2006-09-20 16:05 ` Junio C Hamano
2006-09-20 16:18 ` Petr Baudis
2006-09-20 16:15 ` Linus Torvalds
2006-09-20 19:58 ` Jakub Narebski
3 siblings, 1 reply; 43+ messages in thread
From: Junio C Hamano @ 2006-09-20 16:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: Stephen Hemminger, Jeff Garzik, git, Linus Torvalds
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> said that...
>> However, you can tell git that Jeff is being difficult by marking such
>> branches individually as being rebased.
>
> This is really a wrong way of describing the problem - I'd say that Git
> is being difficult here. The point is, the subsystem maintainers need to
> maintain stacks of patches and rebase against the main kernel branch
> regularily, and they want to still publish their current state. So it's
> not really any of them being strange or difficult, but Git being so
> because it has no seamless support for tracking those branches.
Seamless support is there and Linus described how without
breaking the usual "if not fast forward you may lose some
patches so be extra careful" safety valve.
I do not see what your problem is.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:05 ` Junio C Hamano
@ 2006-09-20 16:18 ` Petr Baudis
2006-09-20 16:33 ` Linus Torvalds
2006-09-20 20:01 ` Jakub Narebski
0 siblings, 2 replies; 43+ messages in thread
From: Petr Baudis @ 2006-09-20 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Hemminger, Jeff Garzik, git, Linus Torvalds
Dear diary, on Wed, Sep 20, 2006 at 06:05:58PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter
> > where Linus Torvalds <torvalds@osdl.org> said that...
> >> However, you can tell git that Jeff is being difficult by marking such
> >> branches individually as being rebased.
> >
> > This is really a wrong way of describing the problem - I'd say that Git
> > is being difficult here. The point is, the subsystem maintainers need to
> > maintain stacks of patches and rebase against the main kernel branch
> > regularily, and they want to still publish their current state. So it's
> > not really any of them being strange or difficult, but Git being so
> > because it has no seamless support for tracking those branches.
>
> Seamless support is there and Linus described how without
> breaking the usual "if not fast forward you may lose some
> patches so be extra careful" safety valve.
I argue that this safety valve is useless for most people (and
actually I have hard time imagining a plausible scenario in which it
actually _is_ useful). The support is not really seamless since you have
to make manual changes to refspecs, while most people probably don't
understand them (and shouldn't be required to if they are just tracking
someone else anyway).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:18 ` Petr Baudis
@ 2006-09-20 16:33 ` Linus Torvalds
2006-09-20 20:01 ` Jakub Narebski
1 sibling, 0 replies; 43+ messages in thread
From: Linus Torvalds @ 2006-09-20 16:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Stephen Hemminger, Jeff Garzik, git
On Wed, 20 Sep 2006, Petr Baudis wrote:
>
> I argue that this safety valve is useless for most people (and
> actually I have hard time imagining a plausible scenario in which it
> actually _is_ useful).
It is only useless for people who use git ass a read-only "anonymous CVS"
kind of thing.
And yes, that may be "most people", but dammit, it's not the group git has
been designed for.
I would be ok with a "anonymous read-only" approach IF GIT ACTUALLY
ENFORCED IT. In other words, we could easily have a read-only clone that
added the "+" to all branches, but then we should also make sure that
nobody ever commits _anything_ in such a repo.
No merges (because you can not rely on the merge result being meaningful:
the sources of the merge may be "ephemeral"), no local commits (because
you can never "pull" any more after that, since that now becomes a merge
with something you can't trust any more).
In other words, if you default to the "+" behaviour, you basically can do
_nothing_ in that repository except just track the other end.
Is that useful? Potentially. But it's so clearly inferior to what we have
now that you should definitely realize that we're not talking about a full
git repository any more, we're really talking about just a "git tracker".
Linus
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:18 ` Petr Baudis
2006-09-20 16:33 ` Linus Torvalds
@ 2006-09-20 20:01 ` Jakub Narebski
1 sibling, 0 replies; 43+ messages in thread
From: Jakub Narebski @ 2006-09-20 20:01 UTC (permalink / raw)
To: git
Petr Baudis wrote:
>> Seamless support is there and Linus described how without
>> breaking the usual "if not fast forward you may lose some
>> patches so be extra careful" safety valve.
>
> I argue that this safety valve is useless for most people (and
> actually I have hard time imagining a plausible scenario in which it
> actually _is_ useful). The support is not really seamless since you have
> to make manual changes to refspecs, while most people probably don't
> understand them (and shouldn't be required to if they are just tracking
> someone else anyway).
Or you can always pull with the --force option...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 15:54 ` Petr Baudis
2006-09-20 16:02 ` Johannes Schindelin
2006-09-20 16:05 ` Junio C Hamano
@ 2006-09-20 16:15 ` Linus Torvalds
2006-09-20 16:59 ` Shawn Pearce
2006-09-23 4:18 ` Petr Baudis
2006-09-20 19:58 ` Jakub Narebski
3 siblings, 2 replies; 43+ messages in thread
From: Linus Torvalds @ 2006-09-20 16:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: Stephen Hemminger, Jeff Garzik, git
On Wed, 20 Sep 2006, Petr Baudis wrote:
>
> This is really a wrong way of describing the problem - I'd say that Git
> is being difficult here.
I'm sorry, but no.
Git has been designed from the ground up for safety and security.
Performance was one big issue, but at every turn, _integrity_ of the
archive has always been a much more important one.
I realize that a lot of people don't think "integrity" matters. I'm sorry,
but those people are simply wrong. In an SCM, "integrity" is the _only_
thing that matters. Everything else is just fluff.
> The point is, the subsystem maintainers need to maintain stacks of
> patches and rebase against the main kernel branch regularily, and they
> want to still publish their current state.
And git supports that.
> So it's not really any of them being strange or difficult, but Git being
> so because it has no seamless support for tracking those branches.
It _does_ have seamless support for tracking those branches, but git had
DAMN WELL BETTER MAKE SURE THAT NO INFORMATION GETS LOST!
That's the one and _only_ thing a SCM had better always guarantee.
The fact that very few systems guarantee it, and that you can mess around
any which way you damn well want in most other systems, without the user
being any wiser is a BUG in those systems. The fact that you can edit
(and/or move around) the raw CVS files after-the-fact, and nobody will
ever know is _bad_. That other systems allow it even today is just a
disgrace.
We may have some bugs in git, but modulo those, I hope the design is
actually very reliable. If you pull from some other repository, you're
guaranteed that you won't suddenly have lost your old state just because
the other end had a mistake.
People had better understand that git does support rebasing, but also
understand that THAT DESTROYS HISTORY. If you don't understand that, then
you shouldn't be told about it. Which is exactly what git does.
The thing is, if you don't understand how rebasing etc destroys history,
you may do things like do a "git pull" or a "git merge" of a branch that
the other side WILL THROW AWAY! That will later result in major pain,
because when you then try to merge it later, you will get all kinds of
nasty behaviour, because the history you merged earlier no longer matches
the history you're now trying to merge again, and the work you merged
earlier is simply not there any more.
See? A "git rebase" has _major_ implications for the receiving end. If git
just silently rebased on the receiving end too, THAT WOULD BE A BUG!
Once you understand this, and you understand what it _means_, you can then
add a "+" in your local .git/remotes/xyzzy file. But git should sure as
hell not allow it by default.
You may think git is being difficult, but the fact is, git is protecting
your data integrity, and protecting your sanity. And if you don't
understand that, then git _should_ refuse to update a branch that you may
have depended on the old contents for, and inform you that something
strange has happened.
All of git depends on history being append-only. The fact that you -can-
rebase does not change that. A rebase is really "create a totally new
branch, delete the old one, and call the new one the same name as you did
the old one".
So it's really no different from you renaming an unrelated branch to a
name that you already used earlier. The recipient really _should_ be told
that the old branch is gone, and replaced with something totally
unrelated.
Linus
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:15 ` Linus Torvalds
@ 2006-09-20 16:59 ` Shawn Pearce
2006-09-20 17:34 ` Linus Torvalds
2006-09-20 23:12 ` Krzysztof Halasa
2006-09-23 4:18 ` Petr Baudis
1 sibling, 2 replies; 43+ messages in thread
From: Shawn Pearce @ 2006-09-20 16:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Stephen Hemminger, Jeff Garzik, git
Linus Torvalds <torvalds@osdl.org> wrote:
> The thing is, if you don't understand how rebasing etc destroys history,
> you may do things like do a "git pull" or a "git merge" of a branch that
> the other side WILL THROW AWAY! That will later result in major pain,
> because when you then try to merge it later, you will get all kinds of
> nasty behaviour, because the history you merged earlier no longer matches
> the history you're now trying to merge again, and the work you merged
> earlier is simply not there any more.
Yet people (typically those new to Git) will still pull or merge
the wrong branch in, work on top of that merge, publish it, others
will build on that... and wham; that topic branch head which you
wanted to rebase prior to merging is now wedged 50 commits deep in
your history.
Just yesterday I found such a case in a shared repository. Now I
have a branch wedged in our shared mainline that I can't get out
and shouldn't have been there in the first place.
If only the shared repository had a way of advising clients that
commits stored in ref 'BAAAD' may not survive and thus shouldn't
be merged. So that git-merge wouldn't let you merge them in.
Unfortunately there isn't a way to do this that's sane so I'm not
even going to try.
Probably what I should have done (now that I think about it) was to
put a check into our update hook on the shared repository to look for
a rebaseable branch (which are listed in some info file) being pushed
into a non-rebaseable one. If that happens then abort the update.
Unfortunately our current Git client (1.4.2)/Git server version(1.3.1)
combinations means we get no output from our update hook when it
fails, so I can't tell the newbie what they did wrong.
--
Shawn.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:59 ` Shawn Pearce
@ 2006-09-20 17:34 ` Linus Torvalds
2006-09-20 23:12 ` Krzysztof Halasa
1 sibling, 0 replies; 43+ messages in thread
From: Linus Torvalds @ 2006-09-20 17:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Petr Baudis, Stephen Hemminger, Jeff Garzik, git
On Wed, 20 Sep 2006, Shawn Pearce wrote:
>
> Yet people (typically those new to Git) will still pull or merge
> the wrong branch in, work on top of that merge, publish it, others
> will build on that... and wham; that topic branch head which you
> wanted to rebase prior to merging is now wedged 50 commits deep in
> your history.
Yes. It might well be a good idea to mark temporary branches some way on
the sending side, and have "git pull" honor that marking by default.
The only really good marking we'd have (unless we extended the protocol a
lot) is name-based, ie we could have a separate directory for "temporary
branches".
Of course, nothing will ever really avoid outright mistakes, which is
probably the bulk of things. I think a lot of those go away when you get
used to the flow, but especially in the beginning, people _will_ make
mistakes.
So maybe trying to avoid them too much is just futile.
Linus
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:59 ` Shawn Pearce
2006-09-20 17:34 ` Linus Torvalds
@ 2006-09-20 23:12 ` Krzysztof Halasa
1 sibling, 0 replies; 43+ messages in thread
From: Krzysztof Halasa @ 2006-09-20 23:12 UTC (permalink / raw)
To: Shawn Pearce
Cc: Linus Torvalds, Petr Baudis, Stephen Hemminger, Jeff Garzik, git
Shawn Pearce <spearce@spearce.org> writes:
> If only the shared repository had a way of advising clients that
> commits stored in ref 'BAAAD' may not survive and thus shouldn't
> be merged.
They could be merged for some temporary purposes, though (such
as compile/run tests). Merging isn't a problem, doing real
development on such material wouldn't be the best idea.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 16:15 ` Linus Torvalds
2006-09-20 16:59 ` Shawn Pearce
@ 2006-09-23 4:18 ` Petr Baudis
1 sibling, 0 replies; 43+ messages in thread
From: Petr Baudis @ 2006-09-23 4:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, git, Junio C Hamano, Stephen Hemminger,
Jeff Garzik
I'm joining several fibres of the thread since we are talking about the
same thing per partes and that's rather confusing.
Dear diary, on Wed, Sep 20, 2006 at 06:26:32PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> Think about it. You and somebody else works on a common branch, using a
> common source repo. When you "fetch", you want to get all the work that
> the other person has done. But you sure as hell don't want that work to
> overwrite your own work.
>
> So what does git do? It notices if you have a local commit on that shared
> branch (because it no longer fast-forwards to the other end), and it tells
> you exactly that: it says that branch so-and-so doesn't fast-forward, and
> refuses to overwrite it.
I'd bite here that if you commit to a branch that you also simultanously
fetch from somewhere else, you're asking for it - but I've never really
used [plain Git]'s branches so perhaps it is a blessed workflow there.
(Cogito won't let you do it.)
Dear diary, on Wed, Sep 20, 2006 at 06:33:42PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> I would be ok with a "anonymous read-only" approach IF GIT ACTUALLY
> ENFORCED IT. In other words, we could easily have a read-only clone that
> added the "+" to all branches, but then we should also make sure that
> nobody ever commits _anything_ in such a repo.
>
> No merges (because you can not rely on the merge result being meaningful:
> the sources of the merge may be "ephemeral"), no local commits (because
> you can never "pull" any more after that, since that now becomes a merge
> with something you can't trust any more).
Well, yes, it gets bad if you just prepend + to all branches:
Dear diary, on Wed, Sep 20, 2006 at 06:15:04PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> The thing is, if you don't understand how rebasing etc destroys history,
> you may do things like do a "git pull" or a "git merge" of a branch that
> the other side WILL THROW AWAY! That will later result in major pain,
> because when you then try to merge it later, you will get all kinds of
> nasty behaviour, because the history you merged earlier no longer matches
> the history you're now trying to merge again, and the work you merged
> earlier is simply not there any more.
This is a very good point.
But this just means that, as others in the thread noted, there needs to
be a reliable way for marking floating branches in the public
repositories and enforcing the implications of that locally (not letting
the user to merge with those).
When I've said "seamless support for floating branches", generally what
I've had on my mind was that it's seamless for the user, that his the
one who pulls them - the developer can be required to do something small
extra to mark those as such.
When you have that, you can just:
(i) Disallow three-way merges with +branches
(ii) Fast-forward of +branches makes you follow the branch' rebase if
the original commit in the branch before fetching equaled your HEAD
commit, and taints your branch against committing unless you switch to
a non-+ branch (or manually untaint your branch)
(iii) Of course enforce the fast-forward restriction for non-+
branches
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: git pull for update of netdev fails.
2006-09-20 15:54 ` Petr Baudis
` (2 preceding siblings ...)
2006-09-20 16:15 ` Linus Torvalds
@ 2006-09-20 19:58 ` Jakub Narebski
2006-09-21 9:14 ` Johannes Schindelin
3 siblings, 1 reply; 43+ messages in thread
From: Jakub Narebski @ 2006-09-20 19:58 UTC (permalink / raw)
To: git
Petr Baudis wrote:
> Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> said that...
>> However, you can tell git that Jeff is being difficult by marking such
>> branches individually as being rebased.
>
> This is really a wrong way of describing the problem - I'd say that Git
> is being difficult here. The point is, the subsystem maintainers need to
> maintain stacks of patches and rebase against the main kernel branch
> regularily, and they want to still publish their current state. So it's
> not really any of them being strange or difficult, but Git being so
> because it has no seamless support for tracking those branches.
There was idea around moving remotes configuration to config file to have
some per branch configureation, including readonly for protecting tracking
branches, marking default branch for merge with (and which tracking
branch(es) to merge)...
...and that included marking branch _on the server side_ as being rebased,
i.e. without preserved history. Unfortunately, the discussion petered out
without changes to git. Branch marked as pu-like would either get '+'
in appropriate Pull line in remotes file generated during clone, or they
wouldn't need '+'.
By the way, there is '--force' option to git-pull/git-fetch...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: git pull for update of netdev fails.
2006-09-20 19:58 ` Jakub Narebski
@ 2006-09-21 9:14 ` Johannes Schindelin
0 siblings, 0 replies; 43+ messages in thread
From: Johannes Schindelin @ 2006-09-21 9:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Hi,
On Wed, 20 Sep 2006, Jakub Narebski wrote:
> Petr Baudis wrote:
>
> > Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter
> > where Linus Torvalds <torvalds@osdl.org> said that...
>
> >> However, you can tell git that Jeff is being difficult by marking such
> >> branches individually as being rebased.
> >
> > This is really a wrong way of describing the problem - I'd say that Git
> > is being difficult here. The point is, the subsystem maintainers need to
> > maintain stacks of patches and rebase against the main kernel branch
> > regularily, and they want to still publish their current state. So it's
> > not really any of them being strange or difficult, but Git being so
> > because it has no seamless support for tracking those branches.
>
> There was idea around moving remotes configuration to config file to have
> some per branch configureation, including readonly for protecting tracking
> branches, marking default branch for merge with (and which tracking
> branch(es) to merge)...
If you want it, go ahead, propose something.
> ...and that included marking branch _on the server side_ as being rebased,
> i.e. without preserved history. Unfortunately, the discussion petered out
> without changes to git.
Not true. We have the [branch "StrangeCase Sensitive/Name"] syntax as a
consequence.
But I agree, nothing came out of the discussion about per-branch settings,
maybe because nobody cared enough?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 43+ messages in thread