Heiko Voigt writes:
> if {$revs eq {}} {
> set revs HEAD
> -} elseif {[lsearch -exact $revs --all] >= 0} {
> - lappend revs HEAD
> +} else {
> + linsert revs 0 --all-include-head
> }
OK. So the new option means "from here on, the meaning of the
'--all' opti
Am 10.07.19 um 20:40 schrieb Junio C Hamano:
> Heiko Voigt writes:
>
>> behavior. How about '--all-include-head'. Then e.g.
>>
>> git rev-parse --all-include-head --all --not origin/master
>>
>> would include the head ref like you proposed below?
>>
>> What do you think? Or would you rather g
On Wed, Jul 10, 2019 at 11:40:50AM -0700, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > behavior. How about '--all-include-head'. Then e.g.
> >
> > git rev-parse --all-include-head --all --not origin/master
> >
> > would include the head ref like you proposed below?
> >
> > What do you th
Heiko Voigt writes:
> behavior. How about '--all-include-head'. Then e.g.
>
> git rev-parse --all-include-head --all --not origin/master
>
> would include the head ref like you proposed below?
>
> What do you think? Or would you rather go the route of changing
> rev-parse behavior?
Depends o
On Mon, Jul 08, 2019 at 10:16:50PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > The "--all" in rev-list family (including "git log") unconditionally
> > include HEAD. The glitch here is that "--all" in rev-parse does
> > not. And 4d5e1b1319 was an attempt to "fix" that, i.e. make
On Mon, Jul 08, 2019 at 09:55:00PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Heiko Voigt writes:
> >
> >> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
> >> 2014-09-09) the intention was to have detached HEAD shown when the --all
> >> argument is given
Junio C Hamano writes:
> The "--all" in rev-list family (including "git log") unconditionally
> include HEAD. The glitch here is that "--all" in rev-parse does
> not. And 4d5e1b1319 was an attempt to "fix" that, i.e. make "--all"
> imply "HEAD".
And it becomes really tempting to get rid of tha
Junio C Hamano writes:
> Heiko Voigt writes:
>
>> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
>> 2014-09-09) the intention was to have detached HEAD shown when the --all
>> argument is given.
>
> The "do we have --all?" test added by that old commit is not quite
> sat
Heiko Voigt writes:
> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
> 2014-09-09) the intention was to have detached HEAD shown when the --all
> argument is given.
The "do we have --all?" test added by that old commit is not quite
satisfying in the first place. E.g. we
Hi Dscho,
On Thu, Jul 04, 2019 at 12:38:44PM +0200, Johannes Schindelin wrote:
> On Thu, 4 Jul 2019, Heiko Voigt wrote:
[...]
> > Signed-off-by: Heiko Voigt
>
> Good description.
Thanks. I am actually surprised that for almost 5 years nobody noticed
this. It seems either nobody is using --not t
Hi Heiko,
On Thu, 4 Jul 2019, Heiko Voigt wrote:
> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
> 2014-09-09) the intention was to have detached HEAD shown when the --all
> argument is given.
>
> This was solved by appending HEAD to the revs list. By doing that the
> be
In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
2014-09-09) the intention was to have detached HEAD shown when the --all
argument is given.
This was solved by appending HEAD to the revs list. By doing that the
behavior using the --not argument is now broken, since that inve
12 matches
Mail list logo
