GIT 0.99.9g is found at usual places. There are a couple of
important changes, as the slow march towards 1.0 continues.
- The RPM package has been split into a few packages by Jim
Radford. Unfortunately I am not equipped sufficiently to
test the resulting RPMs, so please feed me updates and
corrections as needed. I think archimport part needs to be
split out just like its svn/cvs cousins, and perhaps
documentation into another separate package.
- Fredrik Kuivinen's merge-recursive strategy is now the
default merge strategy for two-head merge that happens after
git-pull. I do not expect this to cause major disruptions,
but if this breaks things there is a workaround to override
this [*1*].
Although I did not hear anybody jumping up-and-down to merge
svnimport updates from Yaacov Akiba Slama, I did not hear it
broke things either, so it graduated to the master branch and
included in this release. It obviously improved things for
Yaacov, and I am hoping this would not cause disruptions for
people's existing setup.
Also included are unexciting bits of fixes here and there.
On the "proposed updates" front, things finally seem to be
calming down.
- One important newcomer is git-pack-redundant. It is still in
"pu" not because I doubt what it does is useful, but simply
because I have not had a chance to study how it does its
thing. I expect to fully merge it into "master" before 1.0
happens.
- Among my own toys in the "pu" branch:
- Determination of merge base for Octopus merge was quite
pessimistic, and a proposed fix is in there; since I will
be regularly and frequently doing Octopus merges, I'll soon
know if this change breaks things; otherwise it will
graduate to "master" shortly.
- merge-base computation done by show-branch was a bit loose
compared to the real merge-base, as pointed out by Linus on
the list, although it does not seem to matter too much in
practice. Also I plan to look into merge-base to see if I
can fix the horizon effect cheaply but that work has not
started yet (it is triggered by fairly pathological case).
- I got tired of not being able to get the committer date
(except the raw format which is unreadable) out of git-log,
and added --pretty=fuller format. This should not break
people's existing setup, so I expect it to move to "master"
soon, maybe with a name change if somebody can suggest a
better name for it.
- Change merge-one-file to handle the case where two sides
add the same path differently. Instead of punting, try to
do two-file merge from both sides. This _might_ turn out
to be useful, but I do not know yet, so it won't graduate
to "master" unless somebody convinces me (and the
community) that it is useful in some use-case scenario.
- Add git-lost+found. Currently the implementation stores
found refs under .git/lost+found/{commit,other}
directories, but writing out their object names to the
standard output and let the users decide what to do with
them was suggested on the list by Daniel, which makes sense
as well. There are pros and cons so until we know if it is
useful and if so in what form, it will not come out of "pu"
branch.
- I do not consider either git-shallow-pack and git-changes
"master" material. The former is a hack to create
deliberately broken repository. The latter is supporting a
wrong workflow, as Linus described the other day. You can
temporarily fetch what you want to compare into local
repository and run git-log or git-whatchanged normally.
Oh, and we will not be moving things out of /usr/bin/ during 1.0
timeframe.
[Footnote]
*1* If for whatever reason you would prefer to keep using the
'resolve' strategy as before when you run 'git-pull', you can
either do 'git-pull -s resolve <remote> <refspec>...' on the
command line, or add the following in your .git/config file:
[pull]
twohead = resolve
On the other hand, if you like to try resolve and then
recursive, you can have this instead (the order does matter, the
first one is tried first):
[pull]
twohead = resolve
twohead = recursive
Junio C Hamano wrote:
> - One important newcomer is git-pack-redundant. It is still in
> "pu" not because I doubt what it does is useful, but simply
> because I have not had a chance to study how it does its
> thing. I expect to fully merge it into "master" before 1.0
> happens.
IMHO git-prune-packed should prune redundant pack files...
> Oh, and we will not be moving things out of /usr/bin/ during 1.0
> timeframe.
:( bummer. I do like the elegance of having /usr/bin/git executing
stuff out of /usr/libexec/git.
/usr/libexec/git also makes it IMO cleaner when integrating git plugins
from third parties (rpm -Uvh git-newfeature), because you don't have to
worry about the /usr/bin namespace.
Jeff
Junio C Hamano wrote:
>
> - Add git-lost+found. Currently the implementation stores
> found refs under .git/lost+found/{commit,other}
> directories, but writing out their object names to the
> standard output and let the users decide what to do with
> them was suggested on the list by Daniel, which makes sense
> as well. There are pros and cons so until we know if it is
> useful and if so in what form, it will not come out of "pu"
> branch.
>
May I *STRONGLY* urge you to name that something different.
"lost+found" is a name with special properties in Unix; for example,
many backup solutions will ignore a directory with that name.
-hpa
Jeff Garzik wrote:
>
>> Oh, and we will not be moving things out of /usr/bin/ during 1.0
>> timeframe.
>
>
> :( bummer. I do like the elegance of having /usr/bin/git executing
> stuff out of /usr/libexec/git.
>
> /usr/libexec/git also makes it IMO cleaner when integrating git plugins
> from third parties (rpm -Uvh git-newfeature), because you don't have to
> worry about the /usr/bin namespace.
>
It's nice in concept, but I think there are a lot of reasons why this is
a bad idea:
- "man" doesn't handle it. It would be another thing if "man" could be
taught to understand commands like "man cvs checkout" or "man git fetch".
- There is no general way to teach shells etc about it, for tab
completion etc.
- Makes it harder (but not impossible) to run git from a build directory
without installing it first.
In comparison, the issue of clutter in /usr/bin is actually a pretty
small issue, especially with htree. Most vendors have gone back to
putting everything into /usr/bin since all variants that involve
splitting it up seem to be more of a loss than a gain.
-hpa
"H. Peter Anvin" <[email protected]> writes:
> May I *STRONGLY* urge you to name that something different.
> "lost+found" is a name with special properties in Unix; for example,
> many backup solutions will ignore a directory with that name.
Yeah, the original proposal (in TODO list) explicitly stated why
I chose lost-found instead of lost+found back then, and somebody
on the list (could have been Pasky but I may be mistaken) said
not to worry. In any case, if we go the route Daniel suggests,
we would not be storing anything on the filesystem ourselves so
this would be a non-issue.
Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter
where Junio C Hamano <[email protected]> said that...
> "H. Peter Anvin" <[email protected]> writes:
>
> > May I *STRONGLY* urge you to name that something different.
> > "lost+found" is a name with special properties in Unix; for example,
> > many backup solutions will ignore a directory with that name.
>
> Yeah, the original proposal (in TODO list) explicitly stated why
> I chose lost-found instead of lost+found back then, and somebody
> on the list (could have been Pasky but I may be mistaken) said
> not to worry.
It was the Large Angry SCM. I share your concern.
> In any case, if we go the route Daniel suggests, we would not be
> storing anything on the filesystem ourselves so this would be a
> non-issue.
I like Daniel's route as well, for the separate command. But it would be
nice to also have a way to tell git-fsck-cache to save the lost+found
refs as it goes, much like the filesystem fsck. So if it reports some
unreachable refs, you will not need to tell it to do the same job
_another_ time to find out the refs and pass them to gitk. Then again,
if we do this, the utility of a separate command will be questionable.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
On Thu, 10 Nov 2005, Petr Baudis wrote:
> Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter
> where Junio C Hamano <[email protected]> said that...
> > "H. Peter Anvin" <[email protected]> writes:
> >
> > > May I *STRONGLY* urge you to name that something different.
> > > "lost+found" is a name with special properties in Unix; for example,
> > > many backup solutions will ignore a directory with that name.
> >
> > Yeah, the original proposal (in TODO list) explicitly stated why
> > I chose lost-found instead of lost+found back then, and somebody
> > on the list (could have been Pasky but I may be mistaken) said
> > not to worry.
>
> It was the Large Angry SCM. I share your concern.
>
> > In any case, if we go the route Daniel suggests, we would not be
> > storing anything on the filesystem ourselves so this would be a
> > non-issue.
>
> I like Daniel's route as well, for the separate command. But it would be
> nice to also have a way to tell git-fsck-cache to save the lost+found
> refs as it goes, much like the filesystem fsck. So if it reports some
> unreachable refs, you will not need to tell it to do the same job
> _another_ time to find out the refs and pass them to gitk. Then again,
> if we do this, the utility of a separate command will be questionable.
Maybe git-fsck-objects should have an option to make it note dangling
objects of certain types, and then count these as reachable? (That is, you
want the head of an unreachable chain listed for recovery, but not other
things reachable from it; you also may want the list of blobs and trees
not reachable either from a ref or from something listed for recovery, but
not omitting a blob reachable only from an unreachable tree)
-Daniel
*This .sig left intentionally blank*
On Thu, 10 Nov 2005, Junio C Hamano wrote:
>
> Yeah, the original proposal (in TODO list) explicitly stated why
> I chose lost-found instead of lost+found back then, and somebody
> on the list (could have been Pasky but I may be mistaken) said
> not to worry. In any case, if we go the route Daniel suggests,
> we would not be storing anything on the filesystem ourselves so
> this would be a non-issue.
I don't know how many people do this, but with the current kernel sources,
"git-fsck-cache --full" takes about a minute on a reasonable fast machine
with everything in cache (ie no real disk activity to speak of)
I personally think that's fine, since I repack my trees every once in a
while, and almost never run a "--full" check, I only do incrementals
(which are basically free). And I suspect that I run fsck a lot more than
anybody else does.
But the point is, that if you actually run fsck every time you want to
visualize your pending commits, you're going to feel the pain.
I think having some kind of lost+found so that you don't have to re-run
fsck just because you decided to look at them some other way (use "git
log" instead of "gitk" or whatever) makes a lot of sense. But yes, it
shouldn't really be called "lost+found" due to some rather serious
confusion that can cause.
Linus
On Thu, 10 Nov 2005, Linus Torvalds wrote:
>
> But the point is, that if you actually run fsck every time you want to
> visualize your pending commits, you're going to feel the pain.
^^^^^^^
That should be "dangling", of course.
Linus
Hi,
On Thu, 10 Nov 2005, H. Peter Anvin wrote:
> May I *STRONGLY* urge you to name that something different. "lost+found"
> is a name with special properties in Unix; for example, many backup
> solutions will ignore a directory with that name.
Two reasons against renaming:
- we call it fsck-objects for a reason. We are working on a file system,
which just so happens to be implemented in user space, not kernel space.
If lost+found has to find a new name, so does fsck-objects.
- lost+found has a special meaning, granted. So, a backup would not be
made of it. So what? I *don't* want it backup'ed. I want to repair what
was wrong with it. When I repaired it, the result is stored somewhere
else. To backup lost+found would make as much sense as to backup /tmp.
Ciao,
Dscho
Johannes Schindelin wrote:
>
> Two reasons against renaming:
>
> - we call it fsck-objects for a reason. We are working on a file system,
> which just so happens to be implemented in user space, not kernel space.
> If lost+found has to find a new name, so does fsck-objects.
>
I'm sorry, but that is bull. The problem here isn't the conventional
naming, it's that you're implementing your filesystem on top of another
filesystem, and you're running into a layering conflict.
> - lost+found has a special meaning, granted. So, a backup would not be
> made of it. So what? I *don't* want it backup'ed. I want to repair what
> was wrong with it. When I repaired it, the result is stored somewhere
> else. To backup lost+found would make as much sense as to backup /tmp.
>
The default should ALWAYS be no data loss.
-hpa
Junio C Hamano wrote:
> "H. Peter Anvin" <[email protected]> writes:
>
>
>>May I *STRONGLY* urge you to name that something different.
>>"lost+found" is a name with special properties in Unix; for example,
>>many backup solutions will ignore a directory with that name.
>
>
> Yeah, the original proposal (in TODO list) explicitly stated why
> I chose lost-found instead of lost+found back then, and somebody
> on the list (could have been Pasky but I may be mistaken) said
> not to worry. In any case, if we go the route Daniel suggests,
> we would not be storing anything on the filesystem ourselves so
> this would be a non-issue.
>
Just realized one more issue with this... a lot of non-Unix filesystems
can't deal with files with a + sign.
-hpa