Re: Re: Re: Remove need to untrack before tracking new branch

> On Wed, 2005-04-13 at 11:26 +0200, Petr Baudis wrote:
> > BTW, why aren't we cc'ing the list?
> > 
> 
> Hmm, no reason really.  If you want to, will do next time.
> 
> > Dear diary, on Wed, Apr 13, 2005 at 10:41:12AM CEST, I got a letter
> > where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > > On Wed, 2005-04-13 at 09:54 +0200, Petr Baudis wrote:
> > > PS: not having looked deeper yet, why does fsck-cache always find
> > > unreferenced blobs/commits (no matter what tree is tracked, they stay
> > > the same) ?  And trying to remove them leads to more, which leads to an
> > > empty .git/opjects/ =)  Also, leading to this, will adding an option to
> > > remove disconnected commits/blobs from local commits (that was
> > > disconnected with a pull) be a viable option to add?
> > 
> > fsck-cache is concerned only by the objects database, so all the HEADs
> > are unreferenced commits too. This is a right thing, the HEAD tracking
> > should stay purely in the scripts - if we want to make fsck-cache
> > smarter about that, we should implement git fsck or something.
> > 
> > Killing unreferenced blobs should be safe, I think.
> > 
> > > First, about the 'git diff' thing I asked yesterday .. what I meant, was
> > > should it actually output this:
> > > 
> > > ----
> > > COPYING:  fe2a4177a760fd110e78788734f167bd633be8de 33
> > > Makefile:  929aa49a3dbe683ad52094099797bc636a7949a6 33
> > > README:  46c6a9ea48ddd1dda45ca585f49975a6869ffe51 33
> > > ...
> > > ----
> > > 
> > > Shouldn't it just show actual changes?
> > 
> > This is an actual change. It's just that it's a change to metadata
> > (somewhat esotherically described by the "33"), not the file contents.
> > 
> > BTW, git diff does actually something completely different from git diff
> > with any arguments. It diffs to the directory cache, not to any tree! It
> > just wraps show-diff, which has also a different output format (not
> > outputting "git diffs"). The worst thing is that it requires a different
> > -p option to apply. Someone should purge this wart, I think.
> > 
> 
> Check applied patch (also in the new output).

> > > Also on the same note .. should 'git ci' without listed files to be
> > > committed, really add a reference to all files as it currently do in the
> > > commit/blob/whatever info, instead of just the changed/added files (see
> > > the git-seperate-dir.patch you have not yet commented on for reference)?
> > 
> > ...
> > 
> 
> Patch will also resolve this.

> > > Secondly, how about style/error issues?  Basically on the style front,
> > > currently some scripts use bash - how about pure bash for all:
> > > 
> > > ----
> > > [[ -n ${tracking} ]] && \
> > > ----
> > > 
> > > rather than:
> > > 
> > > ----
> > > [ "$tracking" ] && \
> > > ----
> > > 
> > > as you do not need the quotes, and for checking files, etc, it just do
> > > better handling than single quotes.  I am prepared to do patches if you
> > > like.
> > 
> > Well. I'm just not used to it and not quite sure about how it behaves
> > etc. So far I tried to make it as sh-like as possible, using bash
> > features only when absolutely necessary. I'm not saying this is the best
> > approach, but I wouldn't change it *now* (especially since it would slow
> > me down which I really don't want now) if someone doesn't give me some
> > really compelling arguments.
> > 
> 
> No problem.
> 

> > > 2) Did not add the gitapply.sh that was new in your tree
> > 
> > This very bug should be fixed by introduction of gitapply.sh. ;-)
> > 
> > Actually I forgot to implement this. Fixed now.
> > 
> > > I guess I might have done things wrong (wrong way around)?  But the
> > > actual question is this .. when I tried to switch, it failed on the
> > > gitapply.sh hunk, but went on anyway ... how about doing a patch
> > > --dry-run first, and showing the user what would happen if that fails,
> > > asking for confirmation?
> > 
> > Just s/merge -b/diff/ on the command line and it will show precisely
> > what it is going to apply.  When we get the automatic base detection
> > something to just print the base could be indeed useful.
> > 
> > If that fails, all what will happen is that the user gets rejects. No
> > big deal. He can anytime just back out by
> > 
> > 	git diff | patch -p0 -R
> > 
> > So, what did it "went on" with? The merge (nor the tracked pull) never
> > commits anything. That's up to you, after you resolve the conflicts and
> > make sure everything is right.
> > 
> 
> Ah, right.
> 
> > > I know its in its infancy, but I am not sure on what scm you are basing
> > > it, so not sure how things should behave.
> > 
> > I'm trying to base it on common sense and principle of least surprise.
> > :-)
> > 
> 
> Ok, I'll just bug you then if I am not sure on how you want something ;p