gmane.comp.version-control.git

Re: [PATCH] Teach ignore machinery about pattern "/"

Nguyen Thai Ngoc Duy — 2012-05-26T04:30:36

That calls for bit of testing, which I'll do soon.


I assume you meant the recent sparse-checkout thread. "/" happens to
work due to (probably) a mistake in sparse-checkout v1.7.2 even though
"/" behavior is undefined. This sets a specific behavior to "/" and
makes 1.7.10 treat "/" like 1.7.2.


except that we do the ignoring in (2) but I don't see this as a
meaningful behavior.


The latter. Though there may be two way of interpreting the empty
string as pattern. The computer would happily say "match nothing", but
my human brain tends to thinkg "match everything" as "match nothing"
does not really makes sense as a pattern.


Because I see "/" as a special case of "/foo". It makes more sense
than "/" as a special case of "foo/", at least not without more
thoughts on it.


That's one way of seeing it. What I propose in the patch is "this is
useless no-op pattern (*), let's assign some meaning to it, what makes
most sense"

(*) still needs verification though.

[PATCH 4/3] clone: send diagnostic messages to stderr

Jeff King — 2012-05-26T04:11:35

Putting messages like "Cloning into.." and "done" on stdout
is un-Unix and uselessly clutters the stdout channel. Send
them to stderr.

We have to tweak two tests to accommodate this:

  1. t5601 checks for doubled output due to forking, and
     doesn't actually care where the output goes; adjust it
     to check stderr.

  2. t5702 is trying to test whether progress output was
     sent to stderr, but naively does so by checking
     whether stderr produced any output. Instead, have it
     look for "%", a token found in progress output but not
     elsewhere (and which lets us avoid hard-coding the
     progress text in the test).

Signed-off-by: Jeff King <peff< at >peff.net>
---
This one isn't really related to the other patches in the series, but
while we're on the subject of extremely minor git-clone annoyances, I
thought I'd throw it in as a bonus round.

Arguably the test in t5601 should just go away entirely. stderr tends to
be line-buffered anyway, so the thing it is testing for wouldn't happen.
Not to

Re: [GSoC] Designing a faster index format - Progress report

Nguyen Thai Ngoc Duy — 2012-05-26T04:09:07

No, read_index_from would go through the normal tree->list conversion.
What I'd like to see is what it looks like when a command accesses
index v5 directly in tree form, taking all advantages that tree-form
provides, and how we should deal with old index versions while still
supporting index v5 (without losing tree advantages)

[PATCH 3/3] clone: allow --no-local to turn off local optimizations

Jeff King — 2012-05-26T03:45:50

This is basically the same as using "file://", but is a
little less subtle for the end user.

Signed-off-by: Jeff King <peff< at >peff.net>
---
 Documentation/git-clone.txt |  4 +++-
 builtin/clone.c             | 12 ++++++------
 t/t5701-clone-local.sh      |  5 +++++
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 589f3ce..f388374 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
< at >< at > -51,7 +51,9 < at >< at > OPTIONS
 This is the default when the source repository is specified with
 `/path/to/repo`, but not with a `file://` URL; specifying `--local` with
 a file URL will bypass the regular transport mechanism as if a direct
-path had been provided.
+path had been provided. Specifying `--no-local` will cancel any previous
+`--local`, and will override the default when `/path/to/repo` is given,
+using the regular git transport instead.
 +
 To force copying instead of hardlinking (which may be desirable if you
 are trying

[PATCH 2/3] clone: make --local handle URLs

Jeff King — 2012-05-26T03:45:32

Once upon a time, the --local flag was used to inform git
that it should perform some optimizations when cloning a
local repository. These days, we perform those optimizations
automatically, and --local is largely a no-op. The one
exception is that we will complain when "--local" is given
if hardlinking fails, whereas the default behavior is to
simply fallback to a copy.

Using --local with anything except a local path is also a
no-op, because we never bother to look at the flag. So this:

  git clone --local file:///path/to/repo

silently ignores the local flag, when a more sensible
behavior would be to treat it the same as:

  git clone --local /path/to/repo

Likewise, this:

  git clone --local http://example.com/repo.git

is nonsense, but git silently accepts it.

This patch causes --local to treat file:// URLs as local,
and to flag an error when nonsensical combinations are
requested.

Signed-off-by: Jeff King <peff< at >peff.net>
---
I had hoped this could just be:

  if (opt_local && !prefixcmp(repo_name,

[PATCH 1/3] t5701: modernize style

Jeff King — 2012-05-26T03:42:53

This test is pretty old and did not follow some of our more
modern best practices. In particular:

  1. It chdir'd all over the place, leaving later tests to
     deal with the fallout. Do our chdirs in subshells
     instead.

  2. It did not use test_must_fail.

  3. It did not use test_line_count.

  4. It checked for the non-existence of a ref by looking in the
     .git/refs directory (since we pack refs during clone
     these days, this will always be succeed, making the
     test useless).

     Note that one call to "-e .git/refs/..." remains,
     because it is checking for the existence of a symbolic
     ref, not a ref itself.

Signed-off-by: Jeff King <peff< at >peff.net>
---
I mostly wanted to pull out the repo_is_hardlinked logic for tests I was
about to add, but once I got cleaning, I couldn't stop. And who can
argue with that diffstat?

 t/t5701-clone-local.sh | 73 ++++++++++++++------------------------------------
 1 file changed, 20 insertions(+), 53 deletions(-)

diff --git a/t/t5701-clone-loc

[PATCH 0/3] clone --local fixes

Jeff King — 2012-05-26T03:42:26

Emeric mentioned that he was confused by the behavior of

  git clone --local file:///path/to/repo

in that the --local is silently ignored. Looking over the documentation,
it is quite unclear whether it is supposed to do anything or not. I
don't think it's an especially pressing use case, so one solution could
be to simply clarify the current behavior in the documentation.

However, I figured this should just be a two-line fix to give it more
sensible behavior, so why not just make it to do the sensible thing? And
while my initial version was two lines, it ended up growing to handle
all of the corner cases properly.  So I'm not super-excited about patch
2, but given that it is written, I think it's a reasonable thing to do
(and it is not _too_ complex).

And then while I was on the subject, I did patch 3, which is something
that has bugged me for a long time.

  [1/3]: t5701: modernize style
  [2/3]: clone: make --local handle URLs
  [3/3]: clone: allow --no-local to turn off local optimizations

-Peff

[PATCH] Pass $verbosity from git pull to git rebase

Iustin Pop — 2012-05-26T01:00:09

Currently "git pull -q" only takes effect in merge mode, as commit
7f87aff2 (which introduced "git pull -q") only passes it to
git-merge. This is not nice as a "git pull --rebase -q" will result in
the "Current branch master is up to date.", instead of being quiet.

The patch adds a simple unit-test that checks that the initial pull, a
pull that forwards the head, and a no-op pull are all silent.

Signed-off-by: Iustin Pop <iusty< at >k1024.org>
---
 Please keep me CC-ed, not subscribed to the list.

 git-pull.sh             |    2 +-
 t/t5521-pull-options.sh |   15 ++++++++++++++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..2920c69 100755
--- a/git-pull.sh
+++ b/git-pull.sh
< at >< at > -278,7 +278,7 < at >< at > fi
 merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
 case "$rebase" in
 true)
-eval="git-rebase $diffstat $strategy_args $merge_args"
+eval="git-rebase $diffstat $strategy_args $merge_args $verbosity"
 eval="$eval --onto $merge_head ${

[PATCH] Pass $verbosity from git pull to git rebase

Iustin Pop — 2012-05-26T01:00:39

Currently "git pull -q" only takes effect in merge mode, as commit
7f87aff2 (which introduced "git pull -q") only passes it to
git-merge. This is not nice as a "git pull --rebase -q" will result in
the "Current branch master is up to date.", instead of being quiet.

The patch adds a simple unit-test that checks that the initial pull, a
pull that forwards the head, and a no-op pull are all silent.

Signed-off-by: Iustin Pop <iusty< at >k1024.org>
---
 Please keep me CC-ed, not subscribed to the list.

 git-pull.sh             |    2 +-
 t/t5521-pull-options.sh |   15 ++++++++++++++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..2920c69 100755
--- a/git-pull.sh
+++ b/git-pull.sh
< at >< at > -278,7 +278,7 < at >< at > fi
 merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
 case "$rebase" in
 true)
-eval="git-rebase $diffstat $strategy_args $merge_args"
+eval="git-rebase $diffstat $strategy_args $merge_args $verbosity"
 eval="$eval --onto $merge_head ${

Re: how to share files between machines?

Neal Kreitzinger — 2012-05-25T23:06:45

There could be lots of ways to do this.  Some ideas are:

   - git-remote allows you to communicate exclusively with the box-2-repo.
   - git-branch allows you to have a branch based on origin, and then 
create another branch based on it that has the extra stuff and that is 
the branch you share with box-2-repo.  To incorporate the original 
branch you can rebase on it or merge it in.

The real question is why do you want to do this, and is the above the 
best way to accomplish it.

Less likely, you could also find that git-submodule is your friend and 
you and box-2-repo are using an extra submodule that the origin repo is 
not using.

v/r,
neal

Re: behaviour of .gitignore

Neal Kreitzinger — 2012-05-25T22:41:09

You should be able to click on that commit in gitk and see that the
files were added (confirm you really added them).

If that ignore entry was there when you did the commit then maybe you
never really committed them.

The gitk step above will tell you if they are there.

Its not looking like you really committed them like you thought you did.

If the files were really committed, then you should have that commit in
your history also.  Therefore, you should be able to 'git checkout' 
those files into your worktree.

v/r,
neal

investment proposal

2012-05-25T21:44:24

Can you stand as an Investor to received Tenure Investment Proceeds? If 
interested please reply Email:mrs.edilyn789< at >zhot.net
Mrs Edilyn M Padilla.

Re: [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file

Jeff King — 2012-05-25T21:44:07


That's true, but...


That doesn't solve all problems with multiple versions, though. For
example, this sequence:

  1. User consciously moves to new location, moving ~/.gitconfig to
     ~/.config/git/config (or perhaps they do not do so consciously, but
     do not have a ~/.gitconfig at all, and run "git config --global"
     with the new version.

  2. User runs "git config --global" with an old version of git, which
     writes to ~/.gitconfig.

After step 1, old versions of git will not respect the user's config at
all. This is unavoidable; the old version does not know about the new
location.

But after step 2, _all_ versions of git have stopped respecting the new
location (because ~/.gitconfig takes precedence). Whereas if we read
from everywhere, then it is broken only in older versions (which are
broken anyway).

So I consider it the lesser of two evils. The rule is much simpler: "old
versions of git do not know about this new location". Which is
unavoidable, and easier to explain than "Old versi

Re: [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file

jaseem abid — 2012-05-25T21:26:49

On Sat, May 26, 2012 at 1:17 AM, NGUYEN Huynh Khoi Nguyen
<nguyenhu< at >ensimag.imag.fr> wrote:


If a new config file gets introduced at `~/.config/git/config`, what
will be the new order of config file precedence?

`/etc/gitconfig` > `~/.gitconfig` > `~/.config/git/config`  > `.git/config` or
`/etc/gitconfig` >  `~/.config/git/config` > `~/.gitconfig` > `.git/config` ?

What will be the new flag to access it? I mean anything new like
--system / --global going to be introduced?

Re: [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file

Junio C Hamano — 2012-05-25T21:25:38


Isn't it actually much worse than that?

If you read from .gitconfig and also from the new location, but update
only the new location, people who use two versions of git will be in a
very confusing situation.  Randomly, some of their updates are always in
effect, and others only appear sometimes, and after wasting a lot of time
and hair scratching their heads, they will realize that writing with old
versions of Git will store values to a place visible to both versions,
while writing with new versions will store values to a place visible only
to new versions.

I'd rather see it ignore the new location as long as ~/.gitconfig exists
(and if only the new location exists, read from and write to it), and have
users make a conscious decision to transition.  That is:

 - If ~/.gitconfig exists, do not do anything new.  Just exercise the
   original code.  For these users, ~/.config/ does _not_ exist as far as
   Git is concerned.

 - (optional) If ~/.gitconfig exists, offer _moving_ it to the new
   location afte

LOAN OFFER!!

DANNY XIONG — 2012-05-25T21:14:15

We offer loans at 2% interest rate (Between 1,000 USD to 100,000:00 USD). Get back if interested: 
We will furnish you with further instructions.

Regards,
DR. FLORA CLARK
CHIEF EXECUTIVE OFFICER     
Contact email:aoanloan94< at >mail.com

[ANNOUNCE] Git 1.7.10.3

Junio C Hamano — 2012-05-25T20:54:39

The latest maintenance release Git 1.7.10.3 is now available at
the usual places.

The release tarballs are found at:

    http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

172c6ad5a55276213c5e40b83a4c270f6f931b3e  git-1.7.10.3.tar.gz
c75f9dd4e5157b0c0cb53d67a599b1b038b9c708  git-htmldocs-1.7.10.3.tar.gz
4ae4f9f0f0dc42ad5cb2de309049c953841bc413  git-manpages-1.7.10.3.tar.gz

Also the following public repositories all have a copy of the v1.7.10.3
tag and the maint branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git


Git v1.7.10.3 Release Notes
===========================

Fixes since v1.7.10.2
---------------------

 * The message file for German translation has been updated a bit.

 * Running "git checkout" on an unborn branch used to corrupt HEAD.

 *

Re: credential-helpers + remote-helper, starting point?

Jeff King — 2012-05-25T20:35:44


Exactly. Let me know if you run into any problems.

-Peff

Re: [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file

Jeff King — 2012-05-25T20:30:56


What about reading? For maximum compatibility, we should always read
from _both_ of them, and choose between them only when writing, no? It
looks like your patch will only read from one or the other.

At first people will have only one or the other, but people using
multiple versions of git, or people following already-written
instructions on the web about modifying ~/.gitconfig could end up with
both.


These are both exploitable buffer overflows. Why not use mkpath?


So we open both files. It looks like in an attempt to see if they are
readable. But:

  1. No need to go to that much work. You can just call access(R_OK).

  2. You never close the files, so you are leaking memory and file
     descriptors.


Style. We put whitespace around comparison operators, and we usually
don't refer to NULL specifically, like:

  if (!gitconfig_file && config_file)


So a simpler way to write this section would be something like:

  if (home) {
          const char *path = mkpath("%s/.config/git/config", home);

Re: [GSoC] Designing a faster index format - Progress report

Thomas Gummerer — 2012-05-25T20:15:47

Thanks for your suggestion. How did you think this should be done?
Writing a extra function in ls-files, just for outputting? I don't
think it is necessary to write a extra function, since the result
from the read_index_from function in read-cache is used for that
anyway. Or did you have something different in mind, that I'm missing
here?

--
Thomas

Re: [RFC] Possibility to choose ~/.config/git/config instead of ~/.gitconfig

Jeff King — 2012-05-25T20:11:23


Yes, I have proposed it in multiple forms, and the discussion always
ends in "gross, it's too complex".

If you really want to do it, the recommended way at this point is:

  # review for any issues (1)
  less .gitconfig

  # assuming it's OK, copy into place (2)
  cp .gitconfig .git/config-from-upstream

  # include it
  git config include.path config-from-upstream

And then repeat steps (1) and (2) whenever you want to update from
upstream. That fixes not only the security issues, but also means that
you won't accidentally drop back to some antique bogus config when you
"git checkout $some_old_version".

-Peff