[WARNING] Proposed future changes that are backward incompatible

[WARNING] Proposed future changes that are backward incompatible

[Junio C Hamano]

Here is a list of possible future changes to git that are backward
incompatible that are under discussion on the git mailing list.

None of them will be in the upcoming 1.6.2 release, but some of them are
likely to appear in future versions.  If you think we should not introduce
some of the listed changes, here is a chance to voice your opinions and
make a convincing argument against them, so please do so.  Many people
complained about the removal of many git-foo commands from user's PATH,
which was done in 1.6.0 based on user input, after it happened.  You do
not want to see such a mess happen again.

Thanks.

* refuse push to update the checked out branch in a non-bare repo by default

  Make "git push" into a repository to update the branch that is checked
  out fail by default.  You can countermand this default by setting a
  configuration variable in the receiving repository.

  http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

* git-push to delete the current branch will be refused by default

  Make "git push $there :$killed" to delete the branch that is pointed at
  by its HEAD fail by default.  You can countermand this default by
  setting a configuration variable in the receiving repository.

  http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936

* git-send-email won't make deep threads by default

  Many people said that by default when sending more than 2 patches the
  threading git-send-email makes by default is hard to read, and they
  prefer the default be one cover letter and each patch as a direct
  follow-up to the cover letter.  You can countermand this by setting a
  configuration variable.

  http://article.gmane.org/gmane.comp.version-control.git/109790

* make core.quotepath=false the default

  By default, "git diff" output quotes bytes in pathnames with high bit
  set, primarily to avoid corruption during e-mail based transfer.  This
  however is inconvenient for human readers, and also makes some poorly
  written user scripts that do not unquote them fail.  Change the default
  so that they are not quoted (note that control characters such as HT are
  always quoted).  You can countermand this by setting a configuration
  variable.

  http://thread.gmane.org/gmane.comp.version-control.git/110033

Re: [WARNING] Proposed future changes that are backward incompatible

[George Spelvin]

There's one more change that was suggested that I'd like to propose:
- Make "git grep" search the whole repository by default; include an
  explicit "." path limiter to search only the current directory.

In addition to being more consistent with other commands like "git log",
this saves a lot of typing working in drivers/net/usb/ if the identifier
you're looking for is in include/.  Typing the additional space-dot
is pretty trivial if you want the current directory only.

Re: [WARNING] Proposed future changes that are backward incompatible

[Nicolas Pitre]

On Fri, 27 Feb 2009, George Spelvin wrote:

> There's one more change that was suggested that I'd like to propose:
> - Make "git grep" search the whole repository by default; include an
>   explicit "." path limiter to search only the current directory.

Isn't that already the default?

[nico@xanadu git]$ git grep Alice
Documentation/gittutorial.txt:Suppose that Alice has started a new project with a git repository in
Documentation/gittutorial.txt:This creates a new directory "myrepo" containing a clone of Alice's
Documentation/gittutorial.txt:When he's ready, he tells Alice to pull changes from the repository
Documentation/gittutorial.txt:This merges the changes from Bob's "master" branch into Alice's
Documentation/gittutorial.txt:current branch.  If Alice has made her own changes in the meantime,
Documentation/gittutorial.txt:Note that in general, Alice would want her local changes committed before
Documentation/gittutorial.txt:initiating this "pull".  If Bob's work conflicts with what Alice did since
Documentation/gittutorial.txt:their histories forked, Alice will use her working tree and the index to
Documentation/gittutorial.txt:refuse to merge --- Alice will have to get rid of her local changes in
Documentation/gittutorial.txt:Alice can peek at what Bob did without merging first, using the "fetch"
Documentation/gittutorial.txt:command; this allows Alice to inspect what Bob did, using a special
Documentation/gittutorial.txt:This operation is safe even if Alice has uncommitted local changes.
Documentation/gittutorial.txt:Alice already knows everything that leads to her current state (HEAD),
Documentation/gittutorial.txt:If Alice wants to visualize what Bob did since their histories forked
Documentation/gittutorial.txt:Alice may want to view what both of them did since they forked.
Documentation/gittutorial.txt:After inspecting what Bob did, if there is nothing urgent, Alice may
Documentation/gittutorial.txt:does have something Alice would immediately need, Alice may choose to
Documentation/gittutorial.txt:With this, Alice can perform the first part of the "pull" operation alone using the
Documentation/gittutorial.txt:Unlike the longhand form, when Alice fetches from Bob using a
Documentation/gittutorial.txt:Alice's master branch.
Documentation/gittutorial.txt:After examining those changes, Alice
Documentation/gittutorial.txt:Later, Bob can update his repo with Alice's latest changes using
Documentation/gittutorial.txt:Note that he doesn't need to give the path to Alice's repository;
Documentation/gittutorial.txt:when Bob cloned Alice's repository, git stored the location of her
Documentation/gittutorial.txt:Git also keeps a pristine copy of Alice's master branch under the
t/t5519-push-alternates.sh:	# Project Bob is a fork of project Alice
t/t5519-push-alternates.sh:		# Bob acquires what Alice did in his work tree first.
t/t5519-push-alternates.sh:		# need to send the commit Bob received from Alice
t/t5519-push-alternates.sh:		# to his public repository, as all the object Alice
t/t5519-push-alternates.sh:	# Check that the second commit by Alice is not sent
t/t5519-push-alternates.sh:		# Alice does not care what Bob does.  She does not
t/t5519-push-alternates.sh:		# This time Bob does not pull from Alice, and
t/t5519-push-alternates.sh:		# Alice does not care what Bob does.  She does not
t/t5519-push-alternates.sh:		# This time Bob does not pull from Alice, and
t/t5519-push-alternates.sh:		# necessary tree) in his repository from Alice.


Nicolas

Re: [WARNING] Proposed future changes that are backward incompatible

[Johannes Schindelin]

Hi,

On Fri, 27 Feb 2009, George Spelvin wrote:

> There's one more change that was suggested that I'd like to propose:
> - Make "git grep" search the whole repository by default; include an
>   explicit "." path limiter to search only the current directory.

I use "git grep" in subdirectories extensively, and I like that it does 
_not_ search the whole repository.

Could you suggest a nice way for me to retain that behavior with an 
option?

After all, since you propose a change in behavior, it is _your_ duty to 
provide ways for those who want the old behavior to get at it easily!

In the alternative, I could suggest "git grep -e <expression> HEAD".

Ciao,
Dscho

Re: [WARNING] Proposed future changes that are backward incompatible

[Sverre Rabbelier]

On Fri, Feb 27, 2009 at 20:42, Nicolas Pitre <nico@cam.org> wrote:
> [nico@xanadu git]$ git grep Alice

Now try again from within a subdir ;).

I actually prefer the current behavior, and am a very extensive user
of it. Config option? ;)

-- 
Cheers,

Sverre Rabbelier

Re: [WARNING] Proposed future changes that are backward incompatible

[Junio C Hamano]

"George Spelvin" <linux@horizon.com> writes:

> There's one more change that was suggested that I'd like to propose:
> - Make "git grep" search the whole repository by default; include an
>   explicit "." path limiter to search only the current directory.
>
> In addition to being more consistent with other commands like "git log",
> this saves a lot of typing working in drivers/net/usb/ if the identifier
> you're looking for is in include/.  Typing the additional space-dot
> is pretty trivial if you want the current directory only.

I do not remember it was ever suggested, let alone coming to anything near
consensus.

The only way you could justify such a default change is to say:

    Almost all the time, everybody wants to use this new behaviour; the
    old behaviour is almost never useful in any situation other than a
    narrow corner case; and if somebody wants to do such a useless thing
    in a corner case, he can always add " ." at the end, so nothing is
    lost.

I do not think that is true for the change you are proposing here.  'He
can always add " ." at the end' alone is not a good enough justification.

I however think your use case deserves to be supported, and I would not
mind at all accepting a new "--full-tree" (or some shorter synonym) option
if the patch is cleanly done (hint, hint).

I'd rather not add this to "future changes that are backward incompatible"
list.  It may be a useful new feature, but that is not what the topic of
this thread is about.

Re: [WARNING] Proposed future changes that are backward incompatible

[George Spelvin]

Junio C Hamano <gitster@pobox.com> wrote:

> "George Spelvin" <linux@horizon.com> writes:
>
> > There's one more change that was suggested that I'd like to propose:
> > - Make "git grep" search the whole repository by default; include an
> >   explicit "." path limiter to search only the current directory.
> >
> > In addition to being more consistent with other commands like "git log",
> > this saves a lot of typing working in drivers/net/usb/ if the identifier
> > you're looking for is in include/.  Typing the additional space-dot
> > is pretty trivial if you want the current directory only.
>
> I do not remember it was ever suggested, let alone coming to anything near
> consensus.

The suggestion was in <83vdsefz9j.fsf@kalahari.s2.org>, available as
http://marc.info/?l=git&m=123216049508531
but I agree that there was no consensus.  I just thought this thread was
a good place to elicit discussion, since it would be an incompatible change.

> The only way you could justify such a default change is to say:
>
>     Almost all the time, everybody wants to use this new behaviour; the
>     old behaviour is almost never useful in any situation other than a
>     narrow corner case; and if somebody wants to do such a useless thing
>     in a corner case, he can always add " ." at the end, so nothing is
>     lost.
>
> I do not think that is true for the change you are proposing here.  'He
> can always add " ." at the end' alone is not a good enough justification.

Please forgive me, I thought the above *might* be true, and wanted
to provoke discussion to see how people felt.  The "consistent with
git-log and all that stuff" argument is quite persuasive to me, but it's
a convenience feature, so it depends on how people feel.

> I however think your use case deserves to be supported, and I would not
> mind at all accepting a new "--full-tree" (or some shorter synonym) option
> if the patch is cleanly done (hint, hint).

Hint taken.  Half of the patch is available at
http://marc.info/?l=git&m=123207990016944

Is -t/--full-tree okay?  I'd rather use -a/--all, but that's taken.  -t
isn't used by grep(1) either.


> I'd rather not add this to "future changes that are backward incompatible"
> list.  It may be a useful new feature, but that is not what the topic of
> this thread is about.

Sorry for veering off on an inappropriate tangent.

Re: [WARNING] Proposed future changes that are backward incompatible

[Pascal Obry]

Johannes Schindelin a écrit :
> I use "git grep" in subdirectories extensively, and I like that it does 
> _not_ search the whole repository.

Count me too! I find this feature very important.

> After all, since you propose a change in behavior, it is _your_ duty to 
> provide ways for those who want the old behavior to get at it easily!

Agreed.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: [WARNING] Proposed future changes that are backward incompatible

[Junio C Hamano]

"George Spelvin" <linux@horizon.com> writes:

> The suggestion was in <83vdsefz9j.fsf@kalahari.s2.org>, available as
> http://marc.info/?l=git&m=123216049508531
> but I agree that there was no consensus.  I just thought this thread was
> a good place to elicit discussion, since it would be an incompatible change.
>
>> The only way you could justify such a default change is to say:
>>
>>     Almost all the time, everybody wants to use this new behaviour; the
>>     old behaviour is almost never useful in any situation other than a
>>     narrow corner case; and if somebody wants to do such a useless thing
>>     in a corner case, he can always add " ." at the end, so nothing is
>>     lost.
>>
>> I do not think that is true for the change you are proposing here.  'He
>> can always add " ." at the end' alone is not a good enough justification.
>
> Please forgive me, ...

There is nothing that needs forgiveness.  Discussion is a good thing, as
long as it is not about useless bikeshedding (and I should just learn to
ignore discussions that are useless, instead of getting upset.  Lucikly we
haven't had many).

> ... I thought the above *might* be true, and wanted to provoke
> discussion to see how people felt.

If you suspected that the above may be true, that the new behaviour should
be the default, and that many people may support that view, and wanted to
confirm it, then your justification should have really spelled it out.

> The "consistent with
> git-log and all that stuff" argument is quite persuasive to me, but it's
> a convenience feature, so it depends on how people feel.

Consistency among tools with a similar objective is a good thing to aim
for.

"log" especially "log -p" is about inspecting _changes_ and to understand
the change you would more often than not want to view the change in the
entire context (that is the point of having an atomic while-tree commit).

On the other hand, "grep" is about narrowing down the _state_ you would
want to inspect, and unlike the case when you _inspect changes_ where you
would more often want to have the entire context, you would more often
want to omit unrelated parts of the tree while you are _narrowing down
state_ to inspect.  This is especially true when you run it from a
subdirectory, and by definition when you are already in a subdirectory,
your attention is already narrowed down to the part of the whole tree you
are currently in.

So in that sense, I do not see a "similar objective" between what log and
grep are used for.  They may superficially look similar, but the useful
mode of operation between them can be different because they are used for
different purposes.

Re: [WARNING] Proposed future changes that are backward incompatible

[Markus Heidelberg]

George Spelvin, 27.02.2009:
> There's one more change that was suggested that I'd like to propose:
> - Make "git grep" search the whole repository by default; include an
>   explicit "." path limiter to search only the current directory.
> 
> In addition to being more consistent with other commands like "git log",
> this saves a lot of typing working in drivers/net/usb/ if the identifier
> you're looking for is in include/.

I use ctags from within the editor Vim therefor. Also grepping may show
too many unwanted results.

Markus