Re: git pull (Re: need advice on usage patterns)

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

 



Jonathan Nieder wrote:
> Thomas Rast wrote:
> [...]
> >                       Or worse, verify that their git-reset has
> > --merge by a quick test (1b5b465 is in 1.6.2) but then find that it
> > does not help with backing out of a merge (e11d7b5 is only in 1.7.0!).
> > 
> > Then again, who reads these manpages anyway?  And we shouldn't let old
> > versions get in the way of having consistent and up-to-date docs.  So,
> 
> Agh, surely we can do better.  Maybe:
> 
> 	See linkgit:git-merge[1] for details, including how conflicts
> 	are presented and handled.
> 
> 	ifdef::stalenotes[]
> 	In git 1.7.0 or later, to cancel a conflicting merge, use
> 	`git reset --merge`.
> 	*Warning*: In older versions of git, running 'git pull'
> 	with uncommited changes is discouraged: while possible,
> 	it leaves you in a state that may be hard to back out of
> 	in the case of a conflict.
> 	else::stalenotes[]
> 	To cancel a conflicting merge, use `git reset --merge`.
> 	endif::stalenotes[]

Sounds good.  Maybe you can call this attribute 'webdocs' or so, so
that we have a generic means of modifying the kernel.org hosted docs?

Also, apparently there is no else::...[] so you have to do an
endif/ifndef pair.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: 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]