a few remaining issues...

a few remaining issues...

[Junio C Hamano]

This is not meant to be an exhaustive list, and I probably will
change my mind after I sleep on them, but before I go to bed,
here are a handful of glitches I think are worth fixing.

* Bare repository.

We have a heuristic to determine bareness and change our
behaviour (albeit slightly) based on it.  The heuristic is not
perfect, but the intent is to avoid things that are undesirable
for bare repository when we know (or guess) it is one, and allow
the repository owner to override if we guessed wrong.  Currently
the only such "undesirable thing" is the use of reflog even when
core.logallrefupdates is not set, but we have an RFC patch
floating around to forbid working-tree operations in a bare
repository to prevent accidents from happening.  I think at that
point it may be prudent to also give users a way to mark a bare
repository explicitly as such, say, with "core.bare = true".
Repository creation by init-db and clone with --bare option can
automatically set this, so adding this should not be too painful
for the users.

* Packed refs.

'git-pack-refs --all' leaves heads/ unpacked because they are
expected to change often, but it packs remotes/.  This does not
make any sense (it is another fallout from "separate remote"
layout that many people pushed, even though I was mildly against
it and mostly uninterested in it, and in the retrospect I think
they did not know about or knew but did not tell me about issues
like this, which makes me somewhat unhappy X-<).  I'd like to
change the command not to pack anything but tags/ hierarchy.
This keeps bases/ used by StGIT unpacked, which makes a lot of
sense -- the hierarchy is even more volatile than heads/.

'git-pack-refs' should default to --prune.  There is no point
not to, really.

'git-pack-refs' should probably learn how to unpack, although
there is no real need for it.

* Remote management.

I pushed out 'git-remote' in 'next' tonight, but as I said, I
think it does very limited things it should do in the current
shape.  What it involves is just scripting and requires no deep
core knowledge, so it might be a good project to enhance on for
new people.

Often people suggest "git checkout -b next origin/next" to add
branch.next.remote = origin and branch.next.merge = refs/heads/next.

I do not think it should be the default, but I do understand why
people would want this (what I mean is that I do not think -b
does not imply you would want to keep tracking and merging from
there for almost all the time -- rather I would suspect it would
be 50:50 thing), so I am not opposed to add an easy way to ask
for these two variables to be set up when the new branch is
made.  Perhaps "git checkout -B"?

* Handling paths that are unknown to the index.

I sent out patches tonight to teach "git reset <tree> -- <path>"
to restore the absense of path in the index from the tree
tonight.  There was another one recently brought up on the list:
"git commit -- <path>" for path that is no longer known to the
index.  While jumping the index is a practice I particularly do
not want to encourage by extending git to support it, we already
have support for most of the cases, so I think it makes sense to
do this for consistency.  I haven't thought about the necessary
changes yet, so people can beat me if they want to.  My vague
idea is to check HEAD to see if <path> exists and if so refrain
from complaining.

* Detached HEAD.

You've seen an experimental patch, discussion, and a few
follow-up patches, all in 'pu'.  I'm not actively looking at
this right now.

* Reflogs.

'git reflog show' needs to be done -- and preferrably in a way
that does not add too much code.

After rebasing a huge series, you need to know that N patches
were involved and have to say HEAD@{N}, instead of HEAD@{1}.
This is unfortunate --- we might want to find a way to make the
reflog's recording granularity match the user operation
granularity better.  But this is probably a fairly intrusive
change we would not want right now.

* Misconfigured "tracking branch" refspecs.

There is a special hack in git-pull that passes --update-head-ok
to git-fetch.  This is a workaround for a case where underlying
git-fetch is told to update the current branch that is also used
as a tracking branch.  This can happen either because the user
misconfigured "Pull: refs/heads/master:refs/heads/master", or
the user checked out a tracking branch to take a peek, and
forgot he was on such a branch and issued "git pull".  Both are
much less likely to happen in the separate remote layout, and I
think we should deprecate both --update-head-ok flag in
git-fetch and support for this situation in git-pull.

Instead, we should unconditionally allow fetching into the
current branch for bare repositories.

The reason we should not allow fetching into the current branch
for a repository with a working tree is that allowing so will
make the index and working tree useless.  Such a fetch updates
the value of HEAD, and after that happens the old value of HEAD
is lost and, there is no way to even run a 3-way merge between
the (old) HEAD, index and the working tree.  Even if the old
value of HEAD is kept somewhere before the fetch happens (which
is what --update-head-ok code allows git-pull to do), the
difference between old HEAD and HEAD needs to be propagated to
both index and the working tree separately, so it involves two
3-way merges, which is way complicated than it is really worth.

* Topic management.

In 'todo' branch there is a git-topic script I use to generate
the "What's cooking" messages.  Although the script in its
current form is probably too specific to my workflow (which has
one baseline with two development branches, and names topics in
certain ways -- the latter is customizable from the command
line), I think something like that may be useful for people who
need to manage multiple topic branches.

Re: a few remaining issues...

[Alex Riesen]

On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:
> This is not meant to be an exhaustive list, and I probably will
> change my mind after I sleep on them, but before I go to bed,
> here are a handful of glitches I think are worth fixing.

Maybe we should at least mention another cygwin quirk:
cygwin (or is it its bash?) treats .exe files and +x-files without
extension somehow stupid: it prefers the file without extension
to the .exe. For example, after installation of git-merge-recursive
you have the old python script and git-merge-recursive.exe in
the same directory. Guess which one is used... Right, the old
python script. Same for count-objects and other recently
rewritten scripts.

Re: a few remaining issues...

[Johannes Schindelin]

Hi,

On Fri, 5 Jan 2007, Junio C Hamano wrote:

> * Reflogs.
> 
> 'git reflog show' needs to be done -- and preferrably in a way that does 
> not add too much code.

I do not have time to follow up on my earlier attempts to teach git-log 
about traversing reflogs instead of the commit parents. But Shawn had a 
working proposal, didn't he?

Ciao,
Dscho

Re: a few remaining issues...

[Juergen Ruehle]

Junio C Hamano writes:
 > * Handling paths that are unknown to the index.
 > 
 > I sent out patches tonight to teach "git reset <tree> -- <path>"
 > to restore the absense of path in the index from the tree
 > tonight.  There was another one recently brought up on the list:
 > "git commit -- <path>" for path that is no longer known to the
 > index.  While jumping the index is a practice I particularly do
 > not want to encourage by extending git to support it, we already
 > have support for most of the cases, so I think it makes sense to
 > do this for consistency.  I haven't thought about the necessary
 > changes yet, so people can beat me if they want to.  My vague
 > idea is to check HEAD to see if <path> exists and if so refrain
 > from complaining.

This looks like a job for your para-walk topic. For this git-commit
case we just need a

  git-ls --no-workdir --error-unmatch HEAD -- <pattern>...

to replace git-ls-files. To my untrained eyes it looks like this is
mostly there (AFAICS it doesn't do pattern matching and the
--error-unmatch thingy).

Re: a few remaining issues...

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 5 Jan 2007, Junio C Hamano wrote:
> 
> > * Reflogs.
> > 
> > 'git reflog show' needs to be done -- and preferrably in a way that does 
> > not add too much code.
> 
> I do not have time to follow up on my earlier attempts to teach git-log 
> about traversing reflogs instead of the commit parents. But Shawn had a 
> working proposal, didn't he?

Yes, but my proposal added a lot of code.  Junio's comment is that
he would prefer one that doesn't, such as by reusing as much of the
revision listing machinary as possible.  Which you had looked into
doing.

I myself am also severly lacking in time right now.  *if* I get
any more Git time in the next week its going to be to finish out
some patches on the bash-completion, so I can try to sneak them
into the v1.5.0 release (if possible).  Its unlikely I'll be able
to look at a `reflog show` anytime soon.

-- 
Shawn.

Re: a few remaining issues...

[Junio C Hamano]

Updates to the previous "remaining issues" list before 1.5.0.

* Bare repository.

I think what I have in 'next' to add 'core.bare' configuration
to make the bare repository detection safer is ready to be used
to port the RFC patch from Shawn to forbid working-tree
operations in a bare repository to prevent accidents from
happening.  It would be nice if we can cook it for a few days in
'next' and push it out to 'master' before v1.5.0-rc1.

Volunteers?


* Packed refs.

'git-pack-refs' should default to --prune.  There is no point
not to, really.  Objections?

We _might_ want to teach 'git-pack-refs' how to unpack, although
there is no real need for it.  I do not care too deeply either
way.


* Detached HEAD.

This is now in 'master' ;-).


* Make -u default to 'git-am'.

Since we are talking about allowing potentially incompatible UI
changes in v1.5.0 iff the change improves the general situation,
I would say why not.  I'd add --no-utf8 just in case, but
personally I do not offhand see need for it.  Projects that want
their commit log messages in legacy encoding can and should say
"i18n.commitencoding = EUCJP" or somesuch and they can continue
using their preferred encodings without changing their tools nor
work habit and without having to worry about re-coding errors.

Re: a few remaining issues...

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Updates to the previous "remaining issues" list before 1.5.0.
> ...
> * Detached HEAD.
>
> This is now in 'master' ;-).

Bzzzzzt.

Sorry, it is not.  Although it is in 'next' and I am hoping we
can straighten potential wrinkles out before -rc1.

Re: a few remaining issues...

[Johannes Schindelin]

Hi,

On Fri, 5 Jan 2007, Shawn O. Pearce wrote:

> I myself am also severly lacking in time right now.

Did you have any chance to look at the patch I posted? It adds 
"--walk-reflogs" option to the revision walker, and as long as there is 
reflog information, traverses the commits in that order. It also shows the 
reflog data just below the "commit" line.

Ciao,
Dscho

Re: a few remaining issues...

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 5 Jan 2007, Shawn O. Pearce wrote:
>
>> I myself am also severly lacking in time right now.
>
> Did you have any chance to look at the patch I posted? It adds 
> "--walk-reflogs" option to the revision walker, and as long as there is 
> reflog information, traverses the commits in that order. It also shows the 
> reflog data just below the "commit" line.

What does it do when you say, for example:

	git log --walk-reflogs master..next

I couldn't make heads or tails out of the patch and did not
understand what it was trying to do.  It looked as if you were
making the log traversal machinery to walk _both_ reflog
(probably from the latest to older) and the usual ancestry.

Re: a few remaining issues...

[Johannes Schindelin]

Hi,

On Tue, 9 Jan 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 5 Jan 2007, Shawn O. Pearce wrote:
> >
> >> I myself am also severly lacking in time right now.
> >
> > Did you have any chance to look at the patch I posted? It adds 
> > "--walk-reflogs" option to the revision walker, and as long as there is 
> > reflog information, traverses the commits in that order. It also shows the 
> > reflog data just below the "commit" line.
> 
> What does it do when you say, for example:
> 
> 	git log --walk-reflogs master..next

It means that (ideally) all revisions are shown which are in the reflog 
chain of next, and _not_ in the reflog chain of master.

However, once the reflog traversal hits the oldest reflog entry, it 
reverts to commit parent traversal.

> I couldn't make heads or tails out of the patch and did not understand 
> what it was trying to do.  It looked as if you were making the log 
> traversal machinery to walk _both_ reflog (probably from the latest to 
> older) and the usual ancestry.

Yes, first reflog, then usual ancestry.

Would you want that changed to _only_ reflog traversal?

Ciao,
Dscho

Re: a few remaining issues...

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 9 Jan 2007, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > On Fri, 5 Jan 2007, Shawn O. Pearce wrote:
> > >
> > >> I myself am also severly lacking in time right now.
> > >
> > > Did you have any chance to look at the patch I posted?

No, I had not had a chance to look at it.  I don't see the patch in
my inbox currently, so I must have deleted it earlier.  As much as
I want this feature in 1.5.0's final release I don't really have
the time/inclination to dredge though my own local mailing list
archives or through the online ones to locate it either.

Right now I want to track down a nasty bug in git-http-fetch that I
noticed recently that's keeping me from tracking git.git through an
HTTP proxy, and then I need to do some hacking on this lightweight
subproject implementation I'm working on.  None of the existing
implementations do what I needed over two weeks ago, so I'm writing
my own.  I really need it to be done before the end of the week.

> > > It adds 
> > > "--walk-reflogs" option to the revision walker, and as long as there is 
> > > reflog information, traverses the commits in that order. It also shows the 
> > > reflog data just below the "commit" line.
> > 
> > What does it do when you say, for example:
> > 
> > 	git log --walk-reflogs master..next
> 
> It means that (ideally) all revisions are shown which are in the reflog 
> chain of next, and _not_ in the reflog chain of master.

That makes a lot of sense actually.  Cute feature.
 
> However, once the reflog traversal hits the oldest reflog entry, it 
> reverts to commit parent traversal.

That doesn't make sense...

> > I couldn't make heads or tails out of the patch and did not understand 
> > what it was trying to do.  It looked as if you were making the log 
> > traversal machinery to walk _both_ reflog (probably from the latest to 
> > older) and the usual ancestry.
> 
> Yes, first reflog, then usual ancestry.
> 
> Would you want that changed to _only_ reflog traversal?

Yes.  The old ancestry has nothing to do with my local reflog.  I
want to know where my reflog ends, as there's no record of that
branch's lifespan before that point.

Right now I have a reflog on `pu` which I've had since reflogs were
first introduced last summer.  Yet it only goes back to Dec 23, 2006.
Looking at the old ancestry of pu back into last Oct isn't really
interesting when I'm studying what changes happened to locally.

-- 
Shawn.

Re: a few remaining issues...

[Johannes Schindelin]

Hi,

On Tue, 9 Jan 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > However, once the reflog traversal hits the oldest reflog entry, it 
> > reverts to commit parent traversal.
> 
> That doesn't make sense...
> 
> > On Tue, 9 Jan 2007, Junio C Hamano wrote:
> > 
> > > I couldn't make heads or tails out of the patch and did not understand 
> > > what it was trying to do.  It looked as if you were making the log 
> > > traversal machinery to walk _both_ reflog (probably from the latest to 
> > > older) and the usual ancestry.
> > 
> > Yes, first reflog, then usual ancestry.
> > 
> > Would you want that changed to _only_ reflog traversal?
> 
> Yes.  The old ancestry has nothing to do with my local reflog.  I
> want to know where my reflog ends, as there's no record of that
> branch's lifespan before that point.
> 
> Right now I have a reflog on `pu` which I've had since reflogs were
> first introduced last summer.  Yet it only goes back to Dec 23, 2006.
> Looking at the old ancestry of pu back into last Oct isn't really
> interesting when I'm studying what changes happened to locally.

Fair enough. It actually simplifies the patch. And if you want to dig on, 
you can just "git log pu@{whatever}", right?

So, is this wanted? (If not, I'd rather spend my time on my day job...)

Ciao,
Dscho

Re: a few remaining issues...

[Johannes Schindelin]

Hi,

On Fri, 5 Jan 2007, Alex Riesen wrote:

> On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:
> > This is not meant to be an exhaustive list, and I probably will
> > change my mind after I sleep on them, but before I go to bed,
> > here are a handful of glitches I think are worth fixing.
> 
> Maybe we should at least mention another cygwin quirk:
> cygwin (or is it its bash?) treats .exe files and +x-files without
> extension somehow stupid: it prefers the file without extension
> to the .exe. For example, after installation of git-merge-recursive
> you have the old python script and git-merge-recursive.exe in
> the same directory. Guess which one is used... Right, the old
> python script. Same for count-objects and other recently
> rewritten scripts.

I just sent out a patch in my mail "[PATCH] Makefile: add 
clean-obsolete-scripts target" which should help.

It might be necessary (under obscure circumstances) to remake all and make 
clean-obsolete-scripts again, to remove the correct files. But in general, 
it should be fine to be called just once.

Ciao,
Dscho

Re: a few remaining issues...

[Alex Riesen]

On 1/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:
> > > This is not meant to be an exhaustive list, and I probably will
> > > change my mind after I sleep on them, but before I go to bed,
> > > here are a handful of glitches I think are worth fixing.
> >
> > Maybe we should at least mention another cygwin quirk:
> > cygwin (or is it its bash?) treats .exe files and +x-files without
> > extension somehow stupid: it prefers the file without extension
> > to the .exe. For example, after installation of git-merge-recursive
> > you have the old python script and git-merge-recursive.exe in
> > the same directory. Guess which one is used... Right, the old
> > python script. Same for count-objects and other recently
> > rewritten scripts.
>
> I just sent out a patch in my mail "[PATCH] Makefile: add
> clean-obsolete-scripts target" which should help.

Well, you also have to give people at least notice _when_ the
target should be called. It can take long time until the victim
notices that he has git-branch (from .sh) and git-branch(.exe).
And that in two places: in the installation target directory and
in the build directory (because in windows it is not fcking
possible to remove "." from the beginning of PATH).

> But in general, it should be fine to be called just once.

Don't think so. We still have candidates for conversion
into C (git-checkout and git-commit being my favorites).

Re: a few remaining issues...

[Johannes Schindelin]

Hi,

On Wed, 10 Jan 2007, Alex Riesen wrote:

> On 1/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:
> > > > This is not meant to be an exhaustive list, and I probably will
> > > > change my mind after I sleep on them, but before I go to bed,
> > > > here are a handful of glitches I think are worth fixing.
> > >
> > > Maybe we should at least mention another cygwin quirk:
> > > cygwin (or is it its bash?) treats .exe files and +x-files without
> > > extension somehow stupid: it prefers the file without extension
> > > to the .exe. For example, after installation of git-merge-recursive
> > > you have the old python script and git-merge-recursive.exe in
> > > the same directory. Guess which one is used... Right, the old
> > > python script. Same for count-objects and other recently
> > > rewritten scripts.
> > 
> > I just sent out a patch in my mail "[PATCH] Makefile: add
> > clean-obsolete-scripts target" which should help.
> 
> Well, you also have to give people at least notice _when_ the
> target should be called.

Okay. Fair enough. So maybe this is the wrong approach: maybe the "all" 
target should look for _all_ executables if there is a script of the same 
name, and in that case remove it; and the "install" target should do the 
same in the gitexecdir?

> > But in general, it should be fine to be called just once.
> 
> Don't think so. We still have candidates for conversion
> into C (git-checkout and git-commit being my favorites).

I was referring to

	make clean-obsolete-scripts; make; make clean-obsolete-scripts

being necessary, because the script somehow got a newer time stamp than 
the executable.

But yes, I think there are way more candidates, my pet peeves being 
git-ls-remote and git-fetch.

Ciao,
Dscho

Re: a few remaining issues...

[Alex Riesen]

On 1/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > I just sent out a patch in my mail "[PATCH] Makefile: add
> > > clean-obsolete-scripts target" which should help.
> >
> > Well, you also have to give people at least notice _when_ the
> > target should be called.
>
> Okay. Fair enough. So maybe this is the wrong approach: maybe the "all"
> target should look for _all_ executables if there is a script of the same
> name, and in that case remove it; and the "install" target should do the
> same in the gitexecdir?

...but unless they're in the index and the build directory is a git repo.
It's going to far. I suggest just giving a word of warning on cygwin at
at the end of build. It is the only platform broken in such a stupid way.