Re: git pull (Re: need advice on usage patterns)
- From
Thomas Rast <trast@student.ethz.ch>
- Date
- Jul 27, 2010, 09:13 UTC
- Message-ID
- <201007271113.32711.trast@student.ethz.ch>
- In-Reply-To
- <20100726200613.GB1451@burratino>
Jonathan Nieder wrote:
Show 24 quoted lines
> 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