Re: git 1.4.0 usability problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:
Jeff Garzik <jeff@xxxxxxxxxx> writes:

Here is how to reproduce:

This is not related to the "not clobbering untracked files"
safety valve under discussion, but one thing I noticed.

git clone -l $url/torvalds/linux-2.6.git tmp-2.6
cd tmp-2.6
cp .git/refs/tags/v2.6.12 .git/refs/heads/tmp
git checkout -f tmp

This should never have been supported.  At this point tmp is a
tag object that is under heads/ -- a definite no-no.  We should
make checkout more careful to complain about it.

Doing

        git update-ref refs/heads/tmp $(git rev-parse v2.6.12^0)

instead of "cp" is kosher, and

	git-rev-parse v2.6.12^0 >.git/refs/heads/tmp

is OK under the current implementation of refs.

Sorry about that. The contrived example produced the same results as the real-world example (updating jgarzik/{libata-dev,scsilun-2.6}.git branches).


git pull . master
# watch OBVIOUS FAST-FORWARD MERGE complain about untracked
# working tree files

In any case, here is a patch I think would alleviate your
original problem.

Sorry for the trouble.  I really did not want to disrupt the
workflow of old timers in the name of making it safer for new
people.  Could you comment on whether this is an acceptable
approach?

-- >8 --
[PATCH] Conditionally loosen "no clobber untracked files" safety valve.

This introduces a new configuration item "core.oktoclobber" to
control how untracked working tree file is handled during branch
switching.

The safety valve introduced during 1.4.0 development cycle
refrains from checking out a file that exists in the working
tree, not in the current HEAD tree and exists in the branch we
are switching to, in order to prevent accidental and
irreversible lossage of user data.  This can be controlled by
having core.oktoclobber configuration item:

I'm a bit under the weather today, so I must defer thinking about this. :) But if what Ryan says is true, about simply needing to ditch the "-f" argument I habitually pass to 'git checkout', would that alleviate the need for a patch?

FWIW, my workflow is

	cd /repos
	cd linux-2.6
	git pull
	cd ../libata-dev
	git checkout -f master	# guarantee any WIP goes away
	git pull ../linux-2.6	# update vanilla branch
	git checkout -f upstream# switch to working branch,
				# guarantee any WIP goes away.
	git pull . master	# pull latest upstream updates
	build/test/etc.
	git checkout -f sii-m15w # switch to topic-specific branch,
				 # whose parent is always #upstream
	git pull . upstream
	build/test/etc.
	repeat for several topics (on-going devel branches)
	git checkout -f -b ALL upstream	# create everything-together
					# test branch
	git pull . sii-m15w
	git pull . topicB
	git pull . topicC
	build/test/etc.
	git checkout -f master
	./push		# calls 'git push --force --all $url'

More tomorrow,

	Jeff


-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]