* Re: pseudo initial empty commit and tag for git-log and git-describe?
From: Linus Torvalds @ 2006-09-20 15:12 UTC (permalink / raw)
To: Nguyá»n Thái Ngá»c Duy; +Cc: git
In-Reply-To: <fcaeb9bf0609200658p3f04df7oe91ddb971787bd70@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1106 bytes --]
On Wed, 20 Sep 2006, Nguyá»n Thái Ngá»c Duy wrote:
>
> I'm still uncomfortable with git-log -p unable to show the first
> commit (git-whatchanged too).
Both of those work fine with "--root". That option tells git: "I'm
interested in the root patch too".
It might make sense to have "--root" be the default, but the problem is
that for projects like the Linux kernel where the first commit is a big
import, showing it as a patch simply doesn't make sense.
So it would have to be a per-repository decision, depending on whether the
repo considers the first commit to be an import or not. Maybe a git-config
option?
> Also git-describe refuses to work without any tag.
Now, that's arguably a real bug. You should be able to describe any
commit, and if there's no tag that is reachable from it, the "description"
should probably just be the SHA1 of the commit.
(Side issue: we should probably also accept the output of "git describe"
as a revision name, since it's a bit silly that you can ask git to
"describe" a revision, but then git can't actually use the description
itself ;)
Linus
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Linus Torvalds @ 2006-09-20 15:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, git
In-Reply-To: <20060920080308.673a1e93@localhost.localdomain>
On Wed, 20 Sep 2006, Stephen Hemminger wrote:
>
> This doesn't work with all the branches for some reason. Is this a git
> bug?
It's a "Jeff bug". He rebases some of his branches, and git by default
refuses to throw away the old data (so if the new branch is not a fast
forward, it will _not_ just silently throw away the old state).
However, you can tell git that Jeff is being difficult by marking such
branches individually as being rebased.
The git archive itself has one such branch: Junio re-writes the "pu"
branch all the time, and so it seldom fast-forwards nicely (the thing
about a fast forward is that you do _not_ lose any old history, you only
append to it, while a rebase will throw the old history away and generate
new history in its place).
So for example, for git itself, you might have a "remotes" file like mine:
[torvalds@g5 git]$ cat .git/remotes/parent
URL: master.kernel.org:/pub/scm/git/git
Pull: master:parent
Pull: next:next
Pull: +pu:pu
which just says that the "parent" repo is the master repo for git, and
notice how the "Pull: +pu:pu" line has that extra "+" at the head. That's
a marker that the remote "pu" branch (which is fetched into the _local_
"pu" branch) should be updated even if it doesn't fast-forward.
So you could either mark _all_ the remote branches with the extra "+" (to
say that you always want to fetch that exact state for whatever branch
you're tracking), or you can ask Jeff which branches he expects to do
strange things and just mark those individual ones.
> A temporary workaround is to prune the offending branches locally
> first, but that seems like a hack.
So there's a non-hack version of this as per above, and it's even
documented, although hard to find (see Documentation/pull-fetch-param.txt)
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: Support for custom per-project owner string
From: Petr Baudis @ 2006-09-20 15:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veju6lgxu.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Sep 20, 2006 at 05:02:21PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Also, ideally this would be in the configfile but calling repoconfig for
> > each repository in the index would slow things down way too much.
>
> Hmph. I wonder why. We do read description already from a file
> so maybe we would want a faster way to access the config file to
> grab gitweb.* variables in a single call?
Still, opening files is _much_ faster than executing a tool, I'd say.
--
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
* Re: [PATCH] cvsimport move over to using git for each ref to read refs
From: Junio C Hamano @ 2006-09-20 15:53 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <4511173D.7020702@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> I guess we could teach for-each-ref to output this as well? Perhaps
> something like authorstamp?
I think you can work with "author" or "committer" to grab the
whole raw line.
About the quoting and parsing, language specific quoting mode is
meant for git-for-each-ref to produce a string that can be eval'ed
in the host language. Think of the command as a tool to write a
short program for you.
The original is like this:
# Get the last import timestamps
opendir(D,"$git_dir/refs/heads");
while(defined(my $head = readdir(D))) {
next if $head =~ /^\./;
open(F,"$git_dir/refs/heads/$head")
or die "Bad head branch: $head: $!\n";
chomp(my $ftag = <F>);
close(F);
open(F,"git-cat-file commit $ftag |");
while(<F>) {
next unless /^author\s.*\s(\d+)\s[-+]\d{4}$/;
$branch_date{$head} = $1;
last;
}
close(F);
}
closedir(D);
The purpose of the loop is to grab all branch heads, and grab
author timestamp for all of them, _and_ stash that in
%branch_date hash indexed by head name. You would want to have
something like this executed for each branch:
$refname = %(refname);
$authorline = %(author);
$authorline =~ /^author\s.*\s(\d+)\s[-+]\d{4}$/;
$branch_date{$refname} = $1;
So, you have the tool to write such a program for you, by doing
something like this:
my $template = '
$refname = %(refname);
$authorline = %(author);
$authorline =~ /^author\s.*\s(\d+)\s[-+]\d{4}$/;
$branch_date{$refname} = $1;
';
my @cmd = ('git-for-each-ref', '--perl', "--format=$template");
open I, '-|', @cmd, 'refs/heads';
my $script = join('',<I>);
close I;
my ($refname, $authorline);
eval "$script";
The language specific quoting flag --perl affects how %() are
interpolated into the generated program text as literals.
That's why there is no quote around %(refname) or %(author)
in the example above when defining the $template.
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Petr Baudis @ 2006-09-20 15:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen Hemminger, Jeff Garzik, git
In-Reply-To: <Pine.LNX.4.64.0609200816400.4388@g5.osdl.org>
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.
--
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
* Re: git pull for update of netdev fails.
From: Johannes Schindelin @ 2006-09-20 16:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20060920155431.GO8259@pasky.or.cz>
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
* Re: git pull for update of netdev fails.
From: Junio C Hamano @ 2006-09-20 16:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: Stephen Hemminger, Jeff Garzik, git, Linus Torvalds
In-Reply-To: <20060920155431.GO8259@pasky.or.cz>
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
* Re: [PATCH] Added --mirror-all to git-fetch.
From: Junio C Hamano @ 2006-09-20 16:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060919232851.GA12195@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> The --mirror-all option to git-fetch can be used to obtain a copy of
> every available remote ref into the current repository. This can be
> a rather destructive update as the local repository will have its
> HEAD ref overwritten, as well as any ref which it shares in common
> with the remote repository.
I can sort of see where something like this is very much useful,
but it sounds like a tool quite different from git-fetch.
(1) I really do not like rolling this kind of speciale purpose
command into git-fetch, which is frequently used by end
users, to avoid mistakes.
If there is reluctance against adding yet another new
command (and there certainly is), this feels more like a
cousin of "git-clone --bare".
(2) Although there is no inherent reason not allowing a working
tree associated with the repository that is kept updated
this way, the user will be utterly confused in a working
tree whose current branch head is updated like this, until
the working tree and the index is matched to the updated
HEAD. It might be reasonable to run checkout -f HEAD when
a working tree is associated with the repository (the
command is screwing over even the current branch HEAD, so
losing what happened to be in the working tree is really
not an issue), but as a much easier safety measure we might
want to allow this mode of updating only on a bare
repository (that is, .git/index should not exist).
(3) This feels primarily meant for something like Pasky is
trying to run --- mirrored distribution point of git
repositories perhaps displayed with gitweb. When updating
such a repository, you would want to do things like running
update-server-info and automatically repacking the object
store. Especially the latter would be an interesting topic
(the archive vs active repacking strategy we talked about,
combined with set of packs with staggered spans to help
commit walkers Pasky talked about quite a while ago).
> ...
> such as if you are providing Git repository hosting and mirroring
> source repositories on other systems.
>
> Currently local refs are not deleted even if they do not exist in the
> remote repository. This may be taken as either a feature or a bug.
For that purpose I would say that is definitely a bug.
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Petr Baudis @ 2006-09-20 16:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0609201801110.19042@wbgn013.biozentrum.uni-wuerzburg.de>
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
* Re: [PATCH 1/2] gitweb: Always use git-peek-remote in git_get_references
From: Junio C Hamano @ 2006-09-20 16:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609191431.49641.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Instead of trying to read info/refs file, which might not be present
> (we did fallback to git-ls-remote), always use git-peek-remote in
> git_get_references.
>
> It is preparation for git_get_refs_info to also return references
> info. We cannot use info/refs for git_get_refs_info as the information
> contained therein is usually stale.
What the patch does is sane, but I think the last sentence of
the proposed log message is not. If info/refs is "usually
stale", it is a bug in the repository to have such a stale file.
The real reason for this patch is that a repository served by
gitweb is not necessarily meant to be fetched over HTTP and
info/refs does not have to be there.
^ permalink raw reply
* Re: [PATCH] cvsimport move over to using git for each ref to read refs
From: Andy Whitcroft @ 2006-09-20 16:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodtak00n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
>
>> I guess we could teach for-each-ref to output this as well? Perhaps
>> something like authorstamp?
>
> I think you can work with "author" or "committer" to grab the
> whole raw line.
>
> About the quoting and parsing, language specific quoting mode is
> meant for git-for-each-ref to produce a string that can be eval'ed
> in the host language. Think of the command as a tool to write a
> short program for you.
Thanks for the education. Very simple, and very powerful. I knew there
was a reason for it out there. Will respin a V3 patch in a bit.
-apw
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Joel Dice @ 2006-09-20 16:13 UTC (permalink / raw)
To: git
In-Reply-To: <eeq14e$isu$1@sea.gmane.org>
On Wed, 20 Sep 2006, Jakub Narebski wrote:
> Joel Dice wrote:
>> Well, what it means is "this is the order in which commits were applied to
>> this repository". I suggest that this information is useful for the most
>> common development style - the kind which relies on a central repository
>> as the canonical source for a project's code. "gcc-trunk-r117064" means a
>> lot more to me than "39282037d7cc39829f1d56bf8307b8e5430d585f", and is no
>> less precise.
>
> What about "v1.4.2.1-gf7f93e7", or "tags/v1.4.2-rc4^0~19", or just
> "39282037"? Or "next@{2006-09-19 22:44:33 +0000}"?
The last one is closest to what I want in that it gives me some sense of
the order in which commits appeared in the repository.
Anyway, after some reflection, I've come to the following conclusions:
1. Although the IRN feature would be useful to people like me, it doesn't
fit _naturally_ into Git in particular or DVCSs in general due to the
fact that IRNs are tied to repositories.
2. There are easier, more elegant ways to solve the problem of tying
commits to bug numbers, as Shawn and Johannes pointed out.
So, I'm shelving the IRN idea until and unless I can reconcile it with the
spirit of distributed version control. In the meantime, I plan to pursue
a solution along the lines of Shawn's update hook strategy for bug
tracking, perhaps with the additional step of automatically tagging each
such update.
Thanks for everyone's comments.
- Joel
^ permalink raw reply
* Re: [PATCH] Added --mirror-all to git-fetch.
From: Petr Baudis @ 2006-09-20 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vac4ujzf0.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Sep 20, 2006 at 06:06:11PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
..snip..
> If there is reluctance against adding yet another new
> command (and there certainly is), this feels more like a
> cousin of "git-clone --bare".
Certainly. But, what exactly are you proposing here? :-) (Besides
possible change of the switch name.) Making this a git-clone option
sounds even much worse.
..snip..
> (2) Although there is no inherent reason not allowing a working
> tree associated with the repository that is kept updated
> this way, the user will be utterly confused in a working
> tree whose current branch head is updated like this, until
> the working tree and the index is matched to the updated
> HEAD.
git-fetch --mirror-all can still be very useful even with a working copy
if you are keeping all the remote heads in .git/refs/remotes/. I'd
venture to say that in that case, this is frequently what you actually
want when fetching from the repository (given that you have already let
git clone do that once).
..snip..
> (the archive vs active repacking strategy we talked about,
Hmm, I think I've missed this, I must look that in the archive.
> combined with set of packs with staggered spans to help
> commit walkers Pasky talked about quite a while ago).
Yes, this is certainly one of things I would like to implement at
repo.or.cz.
--
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
* Re: git pull for update of netdev fails.
From: Petr Baudis @ 2006-09-20 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Hemminger, Jeff Garzik, git, Linus Torvalds
In-Reply-To: <7vhcz2jzfd.fsf@assigned-by-dhcp.cox.net>
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
* Re: git pull for update of netdev fails.
From: Linus Torvalds @ 2006-09-20 16:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20060920160756.GP8259@pasky.or.cz>
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
* Re: [PATCH] Added --mirror-all to git-fetch.
From: Shawn Pearce @ 2006-09-20 16:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060920161407.GQ8259@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Sep 20, 2006 at 06:06:11PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
[snip]
> > (2) Although there is no inherent reason not allowing a working
> > tree associated with the repository that is kept updated
> > this way, the user will be utterly confused in a working
> > tree whose current branch head is updated like this, until
> > the working tree and the index is matched to the updated
> > HEAD.
>
> git-fetch --mirror-all can still be very useful even with a working copy
> if you are keeping all the remote heads in .git/refs/remotes/. I'd
> venture to say that in that case, this is frequently what you actually
> want when fetching from the repository (given that you have already let
> git clone do that once).
I think that's more `git fetch --all`. You are pulling every remote
head available at a given remote into a subdirectory of your own ref
space. That's rather different than replacing your entire ref space
with the one available on the remote, which is what --mirror-all
is doing and what you wanted for the hosting you are offering.
> ..snip..
> > (the archive vs active repacking strategy we talked about,
>
> Hmm, I think I've missed this, I must look that in the archive.
Junio pushed the core code out but nobody has done the Porecelain
for it. The basic idea is to prevent repacking every pack all of
the time; there's probably no reason to repack a 100 MiB pack file
every time you repack your loose objects so you might want to keep
say a <5 MiB "active pack" holding your recent created objects
and repack that frequently and a larger 100+ MiB "history pack"
holding everything else. Maybe you repack everything on a longer
time scale, such as once a year.
> > combined with set of packs with staggered spans to help
> > commit walkers Pasky talked about quite a while ago).
>
> Yes, this is certainly one of things I would like to implement at
> repo.or.cz.
Borrowing your line:
Hmm, I think I've missed this, I must look that in the archive.
:-)
--
Shawn.
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Linus Torvalds @ 2006-09-20 16:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: Stephen Hemminger, Jeff Garzik, git
In-Reply-To: <20060920155431.GO8259@pasky.or.cz>
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
* Re: git pull for update of netdev fails.
From: Linus Torvalds @ 2006-09-20 16:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0609200915550.4388@g5.osdl.org>
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
* Re: git pull for update of netdev fails.
From: Shawn Pearce @ 2006-09-20 16:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0609200915550.4388@g5.osdl.org>
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
* Re: [PATCH] Added --mirror-all to git-fetch.
From: Junio C Hamano @ 2006-09-20 16:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Petr Baudis
In-Reply-To: <20060920162145.GA23260@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Petr Baudis <pasky@suse.cz> wrote:
>> Dear diary, on Wed, Sep 20, 2006 at 06:06:11PM CEST, I got a letter
>> where Junio C Hamano <junkio@cox.net> said that...
> [snip]
>> > (2) Although there is no inherent reason not allowing a working
>> > tree associated with the repository that is kept updated
>> > this way, the user will be utterly confused in a working
>> > tree whose current branch head is updated like this, until
>> > the working tree and the index is matched to the updated
>> > HEAD.
>>
>> git-fetch --mirror-all can still be very useful even with a working copy
>> if you are keeping all the remote heads in .git/refs/remotes/. I'd
>> venture to say that in that case, this is frequently what you actually
>> want when fetching from the repository (given that you have already let
>> git clone do that once).
>
> I think that's more `git fetch --all`. You are pulling every remote
> head available at a given remote into a subdirectory of your own ref
> space. That's rather different than replacing your entire ref space
> with the one available on the remote, which is what --mirror-all
> is doing and what you wanted for the hosting you are offering.
I realize I am going around in circles, but Pasky's "remotes/"
argument made me realize that this mirroring is not much more
than "fetch --force --all". I initially had an impression that
this was for only strict mirroring where you do not even want
your own "origin", but if you arrange the .git/remotes/origin
file the right way, "fetch --force --all" (if you remembered to
put '+' in front of the refspecs, even without --force) would
what --mirror-all would do wouldn't it?
Having said that, I am not sure if "fetch --all" should delete
branches that do not exist on the remote end. For mirroring, I
definitely would want the tool to delete them, and that is one
of the reason I feel this is much more similar to git-clone than
git-fetch, unless it is a separate command (perhaps git-mirror).
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Shawn Pearce @ 2006-09-20 16:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0609200920290.4388@g5.osdl.org>
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
* Re: git pull for update of netdev fails.
From: Linus Torvalds @ 2006-09-20 16:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Stephen Hemminger, Jeff Garzik, git
In-Reply-To: <20060920161825.GR8259@pasky.or.cz>
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
* [PATCH] cvsimport move over to using git for each ref to read refs V3
From: Andy Whitcroft @ 2006-09-20 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <45116888.4050806@shadowen.org>
cvsimport: move over to using git-for-each-ref to read refs V3
cvsimport opens all of the files in $GIT_DIR/refs/heads and reads
out the sha1's in order to work out what time the last commit on
that branch was made (in CVS) thus allowing incremental updates.
However, this takes no account of hierachical refs naming producing
the following error for each directory in $GIT_DIR/refs:
Use of uninitialized value in chomp at /usr/bin/git-cvsimport line 503.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-cvsimport line 505.
usage: git-cat-file [-t|-s|-e|-p|<type>] <sha1>
Take advantage of the new packed refs work to use the new
for-each-ref iterator to get this information.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e5a00a1..92d14c3 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -495,22 +495,19 @@ unless(-d $git_dir) {
$tip_at_start = `git-rev-parse --verify HEAD`;
# Get the last import timestamps
- opendir(D,"$git_dir/refs/heads");
- while(defined(my $head = readdir(D))) {
- next if $head =~ /^\./;
- open(F,"$git_dir/refs/heads/$head")
- or die "Bad head branch: $head: $!\n";
- chomp(my $ftag = <F>);
- close(F);
- open(F,"git-cat-file commit $ftag |");
- while(<F>) {
- next unless /^author\s.*\s(\d+)\s[-+]\d{4}$/;
- $branch_date{$head} = $1;
- last;
- }
- close(F);
+ my $fmt = '($ref, $author) = (%(refname), %(author));';
+ open(H, "git-for-each-ref --perl --format='$fmt'|") or
+ die "Cannot run git-for-each-ref: $!\n";
+ while(defined(my $entry = <H>)) {
+ my ($ref, $author);
+ eval($entry) || die "cannot eval refs list: $@";
+
+ next if ($ref !~ m@^refs/heads/(.*)$@);
+ my ($head) = ($1);
+ $author =~ /^.*\s(\d+)\s[-+]\d{4}$/;
+ $branch_date{$head} = $1;
}
- closedir(D);
+ close(H);
}
-d $git_dir
^ permalink raw reply related
* Re: git pull for update of netdev fails.
From: Linus Torvalds @ 2006-09-20 16:38 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <20060920162810.GB23260@spearce.org>
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
* Re: [PATCH] cvsimport move over to using git for each ref to read refs
From: Junio C Hamano @ 2006-09-20 16:45 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <45116888.4050806@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
>> About the quoting and parsing, language specific quoting mode is
>> meant for git-for-each-ref to produce a string that can be eval'ed
>> in the host language. Think of the command as a tool to write a
>> short program for you.
>
> Thanks for the education. Very simple, and very powerful. I knew there
> was a reason for it out there. Will respin a V3 patch in a bit.
This probably showed that my initial description and example for
the feature found in Documentation/git-for-each-ref was lacking.
I would appreciate a separate patch to enhance it if you are so
inclined.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox