date:20130701

1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
2009-10-29) says this is not allowed, as they contradict each other.

However, --ff-only is about asserting the input of the merge, and
--no-ff is about instructing merge to always create a merge commit, i.e.
it makes sense to use these options together in some workflow, e.g. when
branches are integrated by rebasing then merging, and the maintainer
wants to be sure the branch is rebased.

Signed-off-by: Miklos Vajna vmik...@suse.cz
---
 builtin/merge.c  | 12 
 t/t7600-merge.sh | 11 ---
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/builtin/merge.c b/builtin/merge.c
index 2ebe732..7026ce0 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1162,9 +1162,6 @@ int cmd_merge(int argc, const char **argv, const char 
*prefix)
option_commit = 0;
}
 
-   if (!allow_fast_forward  fast_forward_only)
-   die(_(You cannot combine --no-ff with --ff-only.));
-
if (!abort_current_merge) {
if (!argc) {
if (default_to_upstream)
@@ -1433,7 +1430,14 @@ int cmd_merge(int argc, const char **argv, const char 
*prefix)
}
}
 
-   if (fast_forward_only)
+   /*
+* If --ff-only was used without --no-ff, or: --ff-only and --no-ff was
+* used at the same time, and this is not a fast-forward.
+*/
+   if (fast_forward_only  (allow_fast_forward || remoteheads-next ||
+   common-next ||
+   hashcmp(common-item-object.sha1,
+   head_commit-object.sha1)))
die(_(Not possible to fast-forward, aborting.));
 
/* We are going to make a new commit. */
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 460d8eb..bf3d9b2 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -497,9 +497,14 @@ test_expect_success 'combining --squash and --no-ff is 
refused' '
test_must_fail git merge --no-ff --squash c1
 '
 
-test_expect_success 'combining --ff-only and --no-ff is refused' '
-   test_must_fail git merge --ff-only --no-ff c1 
-   test_must_fail git merge --no-ff --ff-only c1
+test_expect_success 'combining --ff-only and --no-ff (ff is possible)' '
+   git reset --hard c0 
+   git merge --ff-only --no-ff c1
+'
+
+test_expect_success 'combining --ff-only and --no-ff (ff is not possible)' '
+   git reset --hard c1 
+   test_must_fail git merge --ff-only --no-ff c2
 '
 
 test_expect_success 'merge c0 with c1 (ff overrides no-ff)' '
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git clone -b

2013-07-01 Thread Stefan Näwe

Am 28.06.2013 13:59, schrieb Stefan Näwe:
 Hi there!
 
 Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
 or a tag (from refs/tags/) ?
 
 Background: At $dayjob we're using some kind of 'hidden' refs (in 
 refs/releases/)
 to communicate between the 'branch integrator' (who creates the ref in 
 refs/releases/)
 and the 'build master' who wants to build that ref. 
 
 It would be a little easier if the build master could simply say
 
   git clone -b refs/releases/the-release-for-today URL
 
 instead of: git clone... ; cd ... ; git fetch... ; git checkout
 
 Any answer or even a better idea to solve that is appreciated.
 
 Stefan
 

Anyone?

Thanks,
  Stefan
-- 

/dev/random says: Some people like learning Eskimo, but I can't get Inuit.
python -c print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] commit: reject invalid UTF-8 codepoints

2013-07-01 Thread Peter Krefting


brian m. carlson:


+   /* Check the value here */
+   if (codepoint = 0xd800  codepoint = 0xdfff)
+   return bad_offset;


if ((x  0xF800) == 0xD800)

is slightly shorter, albeit a bit more difficult to read.

Please also consider adding some commentary as to what you are 
checking here, as it is not obvious unless you know Unicode well.


--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] commit: reject overlong UTF-8 sequences

2013-07-01 Thread Peter Krefting


brian m. carlson:


int offset = 0;
+   static const unsigned int max_codepoint[] = {
+   0x7f, 0x7ff, 0x, 0x1f
+   };


Since Unicode is not defined beyond U+10, you can easily make the 
last range end at U+10FFF. Doing that, ...



if (codepoint  0x10)
return bad_offset;


... you can also drop this test, as it will have been tested by the 
max test already.


--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/5] git-remote-mediawiki: new git bin-wrapper for developement

2013-07-01 Thread Matthieu Moy

Benoît Person benoit.per...@ensimag.fr writes:

 Another idea crossed my mind: for now the test suite creates a symlink
 of git-remote-mediawiki in the toplevel if it's not installed. It
 would be better to use the bin-wrapper in the testsuite I think ?

Absolutely. The symlink was a dirty hack waiting for a better solution,
it even appears in untracked files in git status. This bin-wrapper
should be the better solution hopefully.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] submodule: add 'exec' option to submodule update

2013-07-01 Thread Chris Packham

On 01/07/13 03:30, Jens Lehmann wrote:
 Am 29.06.2013 11:11, schrieb Chris Packham:
 On 28/06/13 22:42, Fredrik Gustafsson wrote:
 technically it looks fine to me (except for the lack of tests) but I'm
 not sure I follow the use case.

 In your case, you want to run a script to determinate if that certain
 submodule should use merge or rebase depending on whatever. And this
 can't be done with git submodule foreach because you want to know the
 sha1 to update to. Have I understood you correctly?

 Correct. We tend to have submodules that are just normal detached heads
 which we don't usually touch and others that are actively developed
 where we would use submodule.x.update=rebase (I personally do) but some
 developers want to use stgit on those repositories.

 Another approach could be to do a 'git pull --no-recurse-submodule' then
 use 'git submodule foreach script-that-does-the-rebase'. The benefit of
 the patch I sent is that it can be setup using the config variables[1]
 and updated the normal way along with the detached HEADs and those using
 plain git branches.
 
 Wouldn't a stgit submodule update (which would do the Right Thing for
 submodules initialized with stgit by maybe just using the pull  foreach
 logic you described) be a better UI for solving your problem?

Yeah I guess so. I was hoping to stay away from an stgit specific
solution but I'm not hearing any other voices looking for such flexibility.

 There may be other use-cases for integration with other tools as well
 (e.g. something that updates a review tool when commits get rebased).

 --
 [1] I'm not crazy about the name of submodule.*.update.command but I
 couldn't think of a better one.
 
 Hmm, if we go that route, why not do the same we do for aliases? If
 the submodule.*.update setting is prefixed with a '!', we just execute
 the shell command following. This would give everyone the freedom to
 do arbitrary stuff if the current none, checkout, merge  rebase won't
 do the trick without having to add another config option.


Make sense. I'll give it a go.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCHv2] submodule: add ability to configure update command

2013-07-01 Thread Chris Packham

Users can set submodule.$name.update to '!command' which will cause
'command' to be run instead of checkout/merge/rebase.  This allows the
user some finer grained control over how the update is done. The primary
motivation for this was interoperability with stgit however being able
to intercept the submodule update process may prove useful for
integrating or extending other tools.

Signed-off-by: Chris Packham judge.pack...@gmail.com
---

On 01/07/13 03:30, Jens Lehmann wrote:

 Hmm, if we go that route, why not do the same we do for aliases? If
 the submodule.*.update setting is prefixed with a '!', we just execute
 the shell command following. This would give everyone the freedom to
 do arbitrary stuff if the current none, checkout, merge  rebase won't
 do the trick without having to add another config option.


And here's an implementation of this. Actually I like this a lot better
to the v1 patch. Still lacks tests but if there is enough interest I can
add some.

 Documentation/git-submodule.txt | 5 -
 git-submodule.sh| 6 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e576713..0befc20 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -159,7 +159,9 @@ update::
This will make the submodules HEAD be detached unless `--rebase` or
`--merge` is specified or the key `submodule.$name.update` is set to
`rebase`, `merge` or `none`. `none` can be overridden by specifying
-   `--checkout`.
+   `--checkout`. Setting the key `submodule.$name.update` to `!command`
+   will cause `command` to be run. `command` can be any arbitrary shell
+   command that takes a single argument, namely the sha1 to update to.
 +
 If the submodule is not yet initialized, and you just want to use the
 setting as stored in .gitmodules, you can automatically initialize the
@@ -172,6 +174,7 @@ If `--force` is specified, the submodule will be checked 
out (using
 `git checkout --force` if appropriate), even if the commit specified in the
 index of the containing repository already matches the commit checked out in
 the submodule.
++
 
 summary::
Show commit summary between the given commit (defaults to HEAD) and
diff --git a/git-submodule.sh b/git-submodule.sh
index eb58c8e..680cb68 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?)
say_msg=$(eval_gettext Submodule path 
'\$prefix\$sm_path': merged in '\$sha1')
must_die_on_failure=yes
;;
+   !*)
+   command=$(expr $update_module : '!\(.*\)')
+   die_msg=$(eval_gettext Unable to exec 
'\$command \$sha1' in submodule path '\$prefix\$sm_path')
+   say_msg=$(eval_gettext Submodule path 
'\$prefix\$sm_path': '\$command \$sha1')
+   must_die_on_failure=yes
+   ;;
*)
command=git checkout $subforce -q
die_msg=$(eval_gettext Unable to checkout 
'\$sha1' in submodule path '\$prefix\$sm_path')
-- 
1.8.3.1.644.g533062f.dirty

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clone: Skip pack-*.keep files when cloning locally

2013-07-01 Thread Jens Lindström

On Fri, Jun 28, 2013 at 8:38 PM, Junio C Hamano gits...@pobox.com wrote:

 The pack-*.keep files are temporary, and serve no purpose in the
 clone.

 They are not temporary, actually. A user can deliberatey create a
 keep marker after packing with a good set of parameters, so that
 the resulting pack will be kept, instead of letting a later repack
 (with faster set of parameters) remove and replace it with less
 optimal results.

Ah, I see.  Was (obviously) not aware of that.  It would perhaps be a
good idea to be able to differentiate between such permanent keep
files and the temporary ones created by built-in commands.

Also, even if some keep files are permanent in the source repository,
is it always a good idea to copy them over to the clone?  This would
only happen for some types of clones, anyway.


On Fri, Jun 28, 2013 at 10:38 PM, Junio C Hamano gits...@pobox.com wrote:

 That is, something like this, perhaps?

Comments:

With this patch, it still fails with --local, when the link() call
fails.  This seems a bit odd, in particular in the cases where --local
is implied.  IOW, one would not expect that adding --local would
change behavior, but here adding it causes the operation to fail.

Also, since failing to link() once implicitly enables --no-hardlinks,
it would copy the rest of the repository without trying to use link(),
which might make the whole operation much more expensive.

Applying the exception for inaccessible .keep files for link() as well
would seem a better solution to me.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] merge: allow using --no-ff and --ff-only at the same time

2013-07-01 Thread Michael Haggerty

On 07/01/2013 09:01 AM, Miklos Vajna wrote:
 1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
 2009-10-29) says this is not allowed, as they contradict each other.
 
 However, --ff-only is about asserting the input of the merge, and
 --no-ff is about instructing merge to always create a merge commit, i.e.
 it makes sense to use these options together in some workflow, e.g. when
 branches are integrated by rebasing then merging, and the maintainer
 wants to be sure the branch is rebased.

That is one interpretation of what these options should mean, and I
agree that it is one way of reading the manpage (which says

--ff-only::
Refuse to merge and exit with a non-zero status unless the
current `HEAD` is already up-to-date or the merge can be
resolved as a fast-forward.

).  However, I don't think that the manpage unambiguously demands this
interpretation, and that (more importantly) most users would be very
surprised if --ff-only and --no-ff were not opposites.

How does it hurt?  If I have configuration value merge.ff set to only
and run git merge --no-ff and then I merge a branch that *cannot* be
fast forwarded, the logic of your patch would require the merge to be
rejected, no?  But I think it is more plausible to expect that the
command line option takes precedence.

Hmmph.  I just tested and found out that (before your patch) a --no-ff
command-line option does *not* override a git config merge.ff only but
rather that the combination provokes the error that you are trying to
remove,

fatal: You cannot combine --no-ff with --ff-only.

I find *that* surprising; usually command-line options override
configuration file settings.  OK, it's time for some more exhaustive
testing:

   situation  merge.ff  option  result
   ---
1  ff possiblefalse --ffworks (ff)
2  ff impossible  false --ffworks (non-ff)
3  ff possiblefalse --ff-only   error cannot combine options
4  ff impossible  false --ff-only   error cannot combine options
5  ff possiblefalse --no-ff works (non-ff)
6  ff impossible  false --no-ff works (non-ff)
7  ff possibleonly  --ffworks (ff)
8  ff impossible  only  --fferror not possible to ff
9  ff possibleonly  --ff-only   works (ff)
10 ff impossible  only  --ff-only   error not possible to ff
11 ff possibleonly  --no-ff error cannot combine options
12 ff impossible  only  --no-ff error cannot combine options

From line 1 we see that --ff overrides merge.ff=false.

From lines 3 and 4 we see that --ff-only cannot be combined with
merge.ff=false.

From line 8 we see that merge.ff=only has its effect despite --ff,
which would normally allow a non-ff merge.

From lines 11 and 12 we see that --no-ff cannot be combined with
merge.ff=only.

I find this inconsistent.  I think it would be more consistent to have
exactly three states,

* merge.ff unset == --ff == do ff if possible, otherwise non-ff

* merge.ff=false == --no-ff == always create merge commit

* merge.ff=only == --ff-only == do ff if possible, otherwise fail

and for the command-line option to always take precedence over the
config file option.

Moreover, isn't it the usual practice for later command-line options to
take precedence over earlier ones?  It is the case for at least one command:

$ git log --oneline --no-walk --no-decorate --decorate
cf71d9b (HEAD, master) 2
$ git log --oneline --no-walk --decorate --no-decorate
cf71d9b 2

So I think that command invocations with more than one of {--ff,
--no-ff, --ff-only} should respect the last option listed rather
than complaining about cannot combine options.

If I find the time (unlikely) I might submit a patch to implement these
expectations.


In my opinion, your use case shouldn't be supported by the command
because (1) it is confusing, (2) it is not very common, and (3) it is
easy to work around:

if git merge-base --is-ancestor HEAD $branch
then
git merge --no-ff $branch
else
echo fatal: Not possible to fast-forward, aborting.
exit 1
fi

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] merge: allow using --no-ff and --ff-only at the same time

Hi Michael,

On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty 
mhag...@alum.mit.edu wrote:
 On 07/01/2013 09:01 AM, Miklos Vajna wrote:
  1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
  2009-10-29) says this is not allowed, as they contradict each other.
  
  However, --ff-only is about asserting the input of the merge, and
  --no-ff is about instructing merge to always create a merge commit, i.e.
  it makes sense to use these options together in some workflow, e.g. when
  branches are integrated by rebasing then merging, and the maintainer
  wants to be sure the branch is rebased.
 
 That is one interpretation of what these options should mean, and I
 agree that it is one way of reading the manpage (which says
 
 --ff-only::
   Refuse to merge and exit with a non-zero status unless the
   current `HEAD` is already up-to-date or the merge can be
   resolved as a fast-forward.
 
 ).  However, I don't think that the manpage unambiguously demands this
 interpretation, and that (more importantly) most users would be very
 surprised if --ff-only and --no-ff were not opposites.

Yes, I agree that that's an unfortunate naming. --ff and --no-ff is the
opposite of each other, however --ff-only is independent, and I would
even rename it to something like --ff-input-only -- but I don't think
it's worth to do so, seeing the cost of it (probably these options are
used by scripts as well).

 How does it hurt?  If I have configuration value merge.ff set to only
 and run git merge --no-ff and then I merge a branch that *cannot* be
 fast forwarded, the logic of your patch would require the merge to be
 rejected, no?  But I think it is more plausible to expect that the
 command line option takes precedence.

Hmm, I did not remember that actually merge.ff even uses the same
configuration slot for these switches. :-( Yes, that would make sense to
fix, once the switches can be combined. Maybe merge.ff and
merge.ff-only?

 In my opinion, your use case shouldn't be supported by the command
 because (1) it is confusing,

I don't see why it would be confusing. I think using these two options
together is one way to try to get the benefits of both rebase (cleaner
history) and merge (keeping the history of which commits came from a
given merge).

 (2) it is not very common,

Hard to argue that argument. :-) No idea what counts as common, my
motivation is that some projects (e.g. syslog-ng) integrate *every*
feature branch this way, and doing this manually (as in indeed
manually or by using a helper script) seems suboptimal, when the support
for this is already mostly in merge.c, just disabled.

 easy to work around:
 
 if git merge-base --is-ancestor HEAD $branch
 then
 git merge --no-ff $branch
 else
 echo fatal: Not possible to fast-forward, aborting.
 exit 1
 fi

Right, that's indeed a viable workaround for the problem.

Miklos


signature.asc
Description: Digital signature

Re: [PATCH] merge: allow using --no-ff and --ff-only at the same time

Michael Haggerty mhag...@alum.mit.edu writes:

 So I think that command invocations with more than one of {--ff,
 --no-ff, --ff-only} should respect the last option listed rather
 than complaining about cannot combine options.

 If I find the time (unlikely) I might submit a patch to implement these
 expectations.

And I wouldn't reject it on the basis of the design --- I agree
fully with your analysis above.  Thanks for digging and spelling out
how they should be fixed.

As to --no-ff vs --ff-only, --ff-only has always meant only
fast-forward updates are allowed.  We do not want to create a merge
commit with this operation.  I do agree with you that the proposed
patch changes the established semantis and may be too disruptive a
thing to do at this point.

 In my opinion, your use case shouldn't be supported by the command
 because (1) it is confusing, (2) it is not very common, and (3) it is
 easy to work around:
 ...

If one were designing Git merge from scratch today, however, I could
see one may have designed these as two orthogonal switches.

 - Precondition on the shape of histories being merged (fail unless
   fast forward does not have to be the only criteria);

 - How the update is done (fast forward to the other head, always
   create a merge, fast forward if possible, otherwise merge do
   not have to be the only three choices).

I do not fundamentally oppose to such a new feature, but they have
to interact sanely with the current --ff={only,only,never}.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] merge: allow using --no-ff and --ff-only at the same time

On Mon, Jul 01, 2013 at 08:38:21AM -0700, Junio C Hamano gits...@pobox.com 
wrote:
 As to --no-ff vs --ff-only, --ff-only has always meant only
 fast-forward updates are allowed.  We do not want to create a merge
 commit with this operation.  I do agree with you that the proposed
 patch changes the established semantis and may be too disruptive a
 thing to do at this point.

Hmm, one way around this may be to add a new option that is basically
the same as --no-ff --ff-only (with the patch), except it has a
different name, so it's not confusing. 'git merge --rebase' could be
used for this, but such a name is misleading as well. Anyone has a
better naming idea? :-)

 If one were designing Git merge from scratch today, however, I could
 see one may have designed these as two orthogonal switches.
 
  - Precondition on the shape of histories being merged (fail unless
fast forward does not have to be the only criteria);
 
  - How the update is done (fast forward to the other head, always
create a merge, fast forward if possible, otherwise merge do
not have to be the only three choices).
 
 I do not fundamentally oppose to such a new feature, but they have
 to interact sanely with the current --ff={only,only,never}.

OK, so if I get it right, the problem is that users got used to that
the --ff-only not only means a precondition for the merge, but also
means either don't create a merge commit or fail, while my patch would
change this second behaviour.

I could imagine then new switches, like 'git merge --pre=ff
--update=no-ff could provide these, though I'm not sure if it makes
sense to add such generic switches till the only user is ff.


signature.asc
Description: Digital signature

Re: [PATCH] clone: Skip pack-*.keep files when cloning locally

Jens Lindström j...@opera.com writes:

 On Fri, Jun 28, 2013 at 8:38 PM, Junio C Hamano gits...@pobox.com wrote:

 The pack-*.keep files are temporary, and serve no purpose in the
 clone.

 They are not temporary, actually. A user can deliberatey create a
 keep marker after packing with a good set of parameters, so that
 the resulting pack will be kept, instead of letting a later repack
 (with faster set of parameters) remove and replace it with less
 optimal results.

 Ah, I see.  Was (obviously) not aware of that.  It would perhaps be a
 good idea to be able to differentiate between such permanent keep
 files and the temporary ones created by built-in commands.

I am not sure if we should care that deeply about them in the first
place.  For these temporary .keep lockfiles to matter, you have to
be doing clone --local --no-hardlinks, which is a cp -R that
bypasses the usual Git transport mechanism, while there is still
activity in the source repository (a fetch is slurping new objects
into a newly created pack with such a temporary .keep lockfile,
the refs may not have been updated yet).  The result is expected to
have inconsistencies even if .keep were readable in such a copy.

 Also, even if some keep files are permanent in the source repository,
 is it always a good idea to copy them over to the clone?

The local cheap cp -R clone are primarily used by people copying
their own private repository that is in a quiescent state, and in
that set-up, copying .keep by default has been a good idea.  Of
course, after copying to a new repository, if they want to repack
with different parameters, they need to unplug .keep files
manually, and it can be argued that the default could have been not
to copy and we could have forced those who want to reuse a tight
pack they created earlier to manually copy or create the .keep
files instead.

 On Fri, Jun 28, 2013 at 10:38 PM, Junio C Hamano gits...@pobox.com wrote:

 That is, something like this, perhaps?

 Comments:

 With this patch, it still fails with --local, when the link() call
 fails.

Oh, I wasn't even attempting to look at the hardlink codepath in the
something like this illustration patch ;-).

Besides, I think you can make a hardlink to a file that you cannot
read.

If you apply only the parts of the patch that adds the test, without
applying either your patch or mine to builtin/clone.c, and remove
--no-hardlinks to force the hardlink codepath, what happens?  We
create an unreadable $keepname in strictsrc repository and I think
the local clone (which is not cp -R but something like find
piped to cpio -pluadm) would make a copy of it just fine.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] t7500: fix flipped actual/expect


Signed-off-by: Andrew Pimlott and...@pimlott.net
---
 t/t7500-commit.sh |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index 436b7b6..e166ac8 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -13,8 +13,8 @@ commit_msg_is () {
expect=commit_msg_is.expect
actual=commit_msg_is.actual
 
-   printf %s $(git log --pretty=format:%s%b -1) $expect 
-   printf %s $1 $actual 
+   printf %s $(git log --pretty=format:%s%b -1) $actual 
+   printf %s $1 $expect 
test_i18ncmp $expect $actual
 }
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] lib-rebase: document exec_ in FAKE_LINES


Signed-off-by: Andrew Pimlott and...@pimlott.net
---
 t/lib-rebase.sh |2 ++
 1 file changed, 2 insertions(+)

diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index cfd3409..7f119e2 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -17,6 +17,8 @@
 #   (squash, fixup, edit, or reword) and the SHA1 taken
 #   from the specified line.
 #
+#   exec_cmd_with_args -- add an exec cmd with args line.
+#
 #   # -- Add a comment line.
 #
 #-- Add a blank line.
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] lib-rebase: use write_script

Excerpts from Junio C Hamano's message of Thu Jun 27 13:50:45 -0700 2013:
 Andrew Pimlott and...@pimlott.net writes:
 
  I should update the function I introduced first.  I will re-submit
  the rebase -i --autosquash patch and wait for acceptance before
  trying to fix other things.
 
 Thanks.

Applies on top of rebase -i patch already accepted.  Mostly whitespace
changes.

Thanks for your other help.

Andrew

---8---
Subject: [PATCH] lib-rebase: style: use write_script, -\EOF


Signed-off-by: Andrew Pimlott and...@pimlott.net
---
 t/lib-rebase.sh |   74 +++
 1 file changed, 36 insertions(+), 38 deletions(-)

diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 7f119e2..8ff87fb 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -24,48 +24,46 @@
 #-- Add a blank line.
 
 set_fake_editor () {
-   echo #!$SHELL_PATH fake-editor.sh
-   cat  fake-editor.sh \EOF
-case $1 in
-*/COMMIT_EDITMSG)
-   test -z $EXPECT_HEADER_COUNT ||
-   test $EXPECT_HEADER_COUNT = $(sed -n '1s/^# This is a 
combination of \(.*\) commits\./\1/p'  $1) ||
+   write_script fake-editor.sh -\EOF
+   case $1 in
+   */COMMIT_EDITMSG)
+   test -z $EXPECT_HEADER_COUNT ||
+   test $EXPECT_HEADER_COUNT = $(sed -n '1s/^# This is 
a combination of \(.*\) commits\./\1/p'  $1) ||
+   exit
+   test -z $FAKE_COMMIT_MESSAGE || echo $FAKE_COMMIT_MESSAGE  
$1
+   test -z $FAKE_COMMIT_AMEND || echo $FAKE_COMMIT_AMEND  
$1
exit
-   test -z $FAKE_COMMIT_MESSAGE || echo $FAKE_COMMIT_MESSAGE  $1
-   test -z $FAKE_COMMIT_AMEND || echo $FAKE_COMMIT_AMEND  $1
-   exit
-   ;;
-esac
-test -z $EXPECT_COUNT ||
-   test $EXPECT_COUNT = $(sed -e '/^#/d' -e '/^$/d'  $1 | wc -l) ||
-   exit
-test -z $FAKE_LINES  exit
-grep -v '^#'  $1  $1.tmp
-rm -f $1
-echo 'rebase -i script before editing:'
-cat $1.tmp
-action=pick
-for line in $FAKE_LINES; do
-   case $line in
-   squash|fixup|edit|reword)
-   action=$line;;
-   exec*)
-   echo $line | sed 's/_/ /g'  $1;;
-   #)
-   echo '# comment'  $1;;
-   )
-   echo  $1;;
-   *)
-   sed -n ${line}s/^pick/$action/p  $1.tmp  $1
-   action=pick;;
+   ;;
esac
-done
-echo 'rebase -i script after editing:'
-cat $1
-EOF
+   test -z $EXPECT_COUNT ||
+   test $EXPECT_COUNT = $(sed -e '/^#/d' -e '/^$/d'  $1 | wc 
-l) ||
+   exit
+   test -z $FAKE_LINES  exit
+   grep -v '^#'  $1  $1.tmp
+   rm -f $1
+   echo 'rebase -i script before editing:'
+   cat $1.tmp
+   action=pick
+   for line in $FAKE_LINES; do
+   case $line in
+   squash|fixup|edit|reword)
+   action=$line;;
+   exec*)
+   echo $line | sed 's/_/ /g'  $1;;
+   #)
+   echo '# comment'  $1;;
+   )
+   echo  $1;;
+   *)
+   sed -n ${line}s/^pick/$action/p  $1.tmp  $1
+   action=pick;;
+   esac
+   done
+   echo 'rebase -i script after editing:'
+   cat $1
+   EOF
 
test_set_editor $(pwd)/fake-editor.sh
-   chmod a+x fake-editor.sh
 }
 
 # After set_cat_todo_editor, rebase -i will write the todo list (ignoring
-- 
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCHv2] submodule: add ability to configure update command

Chris Packham judge.pack...@gmail.com writes:

 Subject: Re: [RFC/PATCHv2] submodule: add ability to configure update command

ability to configure wants to be rephrased to make it more useful
in the shortlog output to help me update release notes ;-)

Subject: [PATCH] submodule update: allow custom update command

perhaps?  We already allow you to configure update command between
merge, rebase and checkout-to-detach, and the value of the change is
to let an arbitrary custom command to be used there.

 And here's an implementation of this. Actually I like this a lot better
 to the v1 patch.

I agree that this looks much more sensible.

Thanks.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] merge: allow using --no-ff and --ff-only at the same time

Miklos Vajna vmik...@suse.cz writes:

 OK, so if I get it right, the problem is that users got used to
 that the --ff-only not only means a precondition for the merge,
 but also means either don't create a merge commit or fail, while
 my patch would change this second behaviour.

It is not just users got used to.  We do not want to create a
merge commit with this operation. is what --ff-only means from
the day one [*1*].

For a merge not to create an extra merge commit, the other history
has to be a proper descendant, but that precondition is a mere
logical consequence of the ultimate goal of the mode.

 I could imagine then new switches, like 'git merge --pre=ff
 --update=no-ff could provide these, though I'm not sure if it makes
 sense to add such generic switches till the only user is ff.

Yes, that is why I said if one were designing it from scratch, I
could see... in a very weak form.


[Footnote]

*1* 13474835 (Teach 'git merge' and 'git pull' the option --ff-only,
2009-10-29) and also $gmane/107768 whose documentation part says:

  Refuse to merge unless the merge is resolved as a fast-forward.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git clone -b

Stefan Näwe stefan.na...@atlas-elektronik.com writes:

 Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
 or a tag (from refs/tags/) ?

Because they are common enough, and doing the same for an arbitrary
object is just as easy to do something like:

git clone -n
git checkout $an_arbitrary_commit_object_name^0

 Background: At $dayjob we're using some kind of 'hidden' refs (in 
 refs/releases/)
 to communicate between the 'branch integrator' (who creates the ref in 
 refs/releases/)
 and the 'build master' who wants to build that ref. 

While I wasn't paying much attention to this, I vaguely recall that
people pointed out that using a fresh clone every time may not be
what you want to do in the first place, and I happen to agree with
them (and that is why I am not very much interested in this topic).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCHv2] submodule: add ability to configure update command

Chris Packham judge.pack...@gmail.com writes:

 + !*)
 + command=$(expr $update_module : '!\(.*\)')

command=${command#!}

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] lib-rebase: use write_script

Andrew Pimlott and...@pimlott.net writes:

 Applies on top of rebase -i patch already accepted.  Mostly whitespace
 changes.

Thanks, will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 0/4] Perl rewrite of Ruby git-related

Eric Sunshine sunsh...@sunshineco.com writes:

 In this submission, the command name has changed to git-contacts since
 git-related felt too generic. (git-contacts seemed best of several
 possibilities I surveyed: git-people, git-interested, git-mentioned,
 git-blame-us.)

I admit I am pretty bad at naming, but contacts sounds like the
most sensible name for what it wants to do (blame-us sounds cute to
my ears, though ;-).

 No attempt is made to answer Junio's v9 review[5], as I lack sufficient
 insight with '-C' options to be able to respond properly.

I just wanted to see if we want to allow the end user of this script
to specify what -C level they want the underlying blame to use, or
just a hardcoded one should suffice (and if so an explanation why).

 My Perl may be rusty and idiomatic usage may be absent.

That is OK.  We need to start somewhere.

Thanks.  Folks, please discuss ;-). 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] t7500: fix flipped actual/expect

Excerpts from Junio C Hamano's message of Mon Jul 01 09:52:05 -0700 2013:
 Wow.  How could all of us missed this for a long time?

:-)  I don't know, but little is more frustrating than a misleading
diagnostic.

BTW, I didn't expect git-send-email to send those two messages in a
thread.  I'll keep them separate next time.

Andrew
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git clone -b

2013-07-01 Thread Phil Hord

It would be nice to support more generic specs for the --branch
switch. But it is complicated because the refs have not been fetched
yet during the clone, and so normal refs operations -- which expect to
work on a local repository -- do not work.  So, the ref is looked up
locally from a list in expected locations after fetching the remote
refs but before the clone occurs.  The remote refs which are fetched
is not configurable during clone, and so only 'refs/heads/*' is
fetched for non-mirrors.

I was able to tweak git-clone to fetch the remote ref when I hacked
builtin/clone.c to check in 'refs' and also to extend the refspec to
something more broad (+refs/*:refs/remotes/origin/*), but this is
not a workable solution.  But there probably is a more correct way
than the hack I tried.

Phil
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 1/4] contrib: add git-contacts helper

Eric Sunshine sunsh...@sunshineco.com writes:

 diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
 new file mode 100755
 index 000..9007bae
 --- /dev/null
 +++ b/contrib/contacts/git-contacts
 @@ -0,0 +1,121 @@
 +#!/usr/bin/perl
 +
 +# List people who might be interested in a patch.  Useful as the argument to
 +# git-send-email --cc-cmd option, and in other situations.
 +#
 +# Usage: git contacts file
 +
 +use strict;
 +use warnings;
 +use IPC::Open2;
 +
 +my $since = '5-years-ago';
 +my $min_percent = 10;
 +my $labels_rx = qr/(?:Signed-off|Reviewed|Acked)-by/;

Although I personally do not see particuarly a good reason to do so,
I have seen people add Cc: on the footers, and I suspect they may
expect them to be also picked up as relevant parties to the
change.  Also S-o-b is often misspelled as Signed-Off-By, so you
may want to do qr//i this one.

 +my $id_rx = qr/[0-9a-f]{40}/i;

On the other hand, we always mark the this is a format-patch
output marker lines with lowercase hex, so you would want to lose
'i' from here.

And you probably want to tighten it even more, perhaps
like so:

qr/^From ([0-9a-f]{40}) Mon Sep 17 00:00:00 2001$/

Of course, you wuold need to have a separate regular expression to
parse git blame --incremental/--porcelain output that may read
perhaps like so:

qr/^([0-9a-f]{40})[ *](\d) (\d) (\d)$/

to pick up only the group header.  The last \d is the number of
lines that came from this guilty party, and it might become useful
if we want to give weight to people based on line-count, not just
number of commits.

 +sub format_contact {
 + my ($name, $email) = @_;
 + return $name $email;
 +}
 +
 +sub parse_commit {
 + my ($commit, $data) = @_;
 + my $contacts = $commit-{contacts};
 + my $inbody = 0;
 + for (split(/^/m, $data)) {
 + if (not $inbody) {
 + if (/^author ([^]+) (\S+) .+$/) {
 + $contacts-{format_contact($1, $2)} = 1;

The author name and email can be grabbed from the blame output
without doing this (and the result may be more robust), but you
would need to read from the log message anyway, so I think this is
OK.

Note that the names and emails in blame output are sanitized via the
mailmap mechanism, but cat-file commit will certainly not be.

You may have to do the mapping yourself by reading the mailmap for
the names and addresses you read from S-o-b: and friends.

 + } elsif (/^$/) {
 + $inbody = 1;
 + }
 + } elsif (/^$labels_rx:\s+([^]+)\s+(\S+?)$/o) {
 + $contacts-{format_contact($1, $2)} = 1;
 + }
 + }
 +}
 +
 +sub import_commits {
 + my ($commits) = @_;
 + return unless %$commits;
 + my $pid = open2 my $reader, my $writer, qw(git cat-file --batch);

Hmph.

I vaguely recall that people wanted not to use open2/IPC::Open2 in
other parts of the system.

I think cat-file --batch is designed to behave on a regular bidi
pipe, as long as the caller strictly does a ping-pong of issuing one
request, flush (with an empty line) and always read the response, so
if open2 becomes problematic, we could switch to regular pipes.

 + for my $id (keys(%$commits)) {
 + print $writer $id\n;
 + my $line = $reader;
 + if ($line =~ /^($id_rx) commit (\d+)/o) {
 + my ($cid, $len) = ($1, $2);
 + die expected $id but got $cid unless $id eq $cid;
 + my $data;
 + # cat-file emits newline after data, so read len+1
 + read $reader, $data, $len + 1;
 + parse_commit($commits-{$id}, $data);
 + }
 + }
 + close $reader;
 + close $writer;
 + waitpid($pid, 0);
 + die git-cat-file error: $? if $?;
 +}
 +
 +sub get_blame {
 + my ($commits, $source, $start, $len, $from) = @_;
 + $len = 1 unless defined($len);
 + return if $len == 0;
 + open my $f, '-|',
 + qw(git blame --incremental -C -C), '-L', $start,+$len,
 + '--since', $since, $from^, '--', $source or die;

--incremental is meant for consumers that wants better latency,
not necessarily better throughput, but I think this consumer does
not present incremental result to the end user, so perhaps you would
want to use --porcelain instead.

 + while ($f) {
 + if (/^$id_rx/o) {
 + my $id = $;
 + $commits-{$id} = { id = $id, contacts = {} };
 + }
 + }
 + close $f;
 +}
 +
 +sub scan_hunks {
 + my ($commits, $id, $f) = @_;
 + my $source;
 + while ($f) {
 + if (/^---\s+(\S+)/) {

I wonder what happens to a patch that touches a file with SP in its
path with this regular expression.  As it is fairly clear that you
are reading from format-patch output (the caller does not call this

Re: [PATCH 09/16] documentation: add documentation for the bitmap format

2013-07-01 Thread Colby Ranger

 Right, the format and implementation in JGit can do Counting objects
 in 87ms for the Linux kernel history.

Actually, that was the timing when I first pushed the change. With the
improvements submitted throughout the year, we can do counting in
50ms, on my same machine.

 But I think we are comparing
 apples to steaks here, Vincent is (rightfully) concerned about process
 startup performance, whereas our timings were assuming the process was
 already running.


I did some timing on loading the reverse index for the kernel and it
is pretty slow (~1200ms). I just submitted a fix to do a bucket sort
and reduced that to ~450ms, which is still slow but much better:
https://eclipse.googlesource.com/jgit/jgit/+/6cc532a43cf28403cb623d3df8600a2542a40a43%5E%21/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 2/4] contrib: contacts: add support for multiple patches

Eric Sunshine sunsh...@sunshineco.com writes:

 Accept multiple patch files rather than only one. For example:

   % git contacts feature/*.patch

 Signed-off-by: Eric Sunshine sunsh...@sunshineco.com

 @@ -93,6 +96,7 @@ sub commits_from_patch {
   while ($f) {
   if (/^From ($id_rx) /o) {
   $id = $1;
 + $seen{$id} = 1;
   last;
   }
   }

This looks less useful than it could be.

$ git format-patch --stdout -4 P.mbox
$ git contacts P.mbox

would have the same number of patches but in a single file.

Wouldn't it be more useful to do something like

$id = undef;
while ($f) {
if (/^From ([0-9a-f]{40}) Mon Sep 17 00:00:00 2001$/) {
# beginning of a patch
$id = $1;
}
next if (!defined $id);
# inline the body of scan_hunks here...
if (m{^--- (a/.*|/dev/null)$}) {
$source = ...
} elsif (/^@@ -(\d+)...) {
get_blame();
}
}

 @@ -100,10 +104,8 @@ sub commits_from_patch {
   close $f;
  }
  
 -exit 1 unless @ARGV == 1;
 -
  my %commits;
 -commits_from_patch(\%commits, $ARGV[0]);
 +commits_from_patch(\%commits, $_) for (@ARGV);

This change does not seem to account for an invocation without any
argument.  Perhaps write it like so to make it more readable?

if (!@ARGV) {
die No input file?\n;
}

for (@ARGV) {
commits_from_patch(\%commits, $_);
}   

  import_commits(\%commits);
  
  my %count_per_person;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 2/4] contrib: contacts: add support for multiple patches

Junio C Hamano gits...@pobox.com writes:

   while ($f) {
   if (/^From ([0-9a-f]{40}) Mon Sep 17 00:00:00 2001$/) {
   # beginning of a patch
   $id = $1;
   }
 next if (!defined $id);
   # inline the body of scan_hunks here...

Or alternatively, teach scan_hunks to stop reading when it sees the
beginning of the next patch (and probably you would need to return
the $id you read, as it would be more cumbersome to rewind the
input stream).

   if (m{^--- (a/.*|/dev/null)$}) {
   $source = ...
   } elsif (/^@@ -(\d+)...) {
   get_blame();
   }
   }

 @@ -100,10 +104,8 @@ sub commits_from_patch {
  close $f;
  }
  
 -exit 1 unless @ARGV == 1;
 -
  my %commits;
 -commits_from_patch(\%commits, $ARGV[0]);
 +commits_from_patch(\%commits, $_) for (@ARGV);

 This change does not seem to account for an invocation without any
 argument.  Perhaps write it like so to make it more readable?

   if (!@ARGV) {
   die No input file?\n;
   }

   for (@ARGV) {
   commits_from_patch(\%commits, $_);
   }   

  import_commits(\%commits);
  
  my %count_per_person;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] t4205: replace .\+ with ..* in sed commands

2013-07-01 Thread Brian Gernhardt

OS X's sed only accepts basic regular expressions, which does not
allow the + quantifier.  However '..*' (anything, followed by zero or
more anything) is the same as '.\+' (one or more anything) and valid
in any regular expression language.

Signed-off-by: Brian Gernhardt br...@gernhardtsoftware.com
---
 t/t4205-log-pretty-formats.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 719d132..3cfb744 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -192,7 +192,7 @@ test_expect_success 'left alignment formatting with trunc' 
 message ..
 message ..
 add bar  Z
-$(commit_msg  8 .\+$)
+$(commit_msg  8 ..*$)
 EOF
test_cmp expected actual
 
@@ -310,7 +310,7 @@ test_expect_success 'left/right alignment formatting with 
stealing' 
 short long  long long
 message ..   A U Thor
 add bar  A U Thor
-$(commit_msg  8 .\+$)   A U Thor
+$(commit_msg  8 ..*$)   A U Thor
 EOF
test_cmp expected actual
 
-- 
1.8.3.1.636.g893104c

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/16] documentation: add documentation for the bitmap format

2013-07-01 Thread Shawn Pearce

On Mon, Jul 1, 2013 at 11:47 AM, Colby Ranger cran...@google.com wrote:
But I think we are comparing
apples to steaks here, Vincent is (rightfully) concerned about process
startup performance, whereas our timings were assuming the process was
already running.

I did some timing on loading the reverse index for the kernel and it
is pretty slow (~1200ms). I just submitted a fix to do a bucket sort
and reduced that to ~450ms, which is still slow but much better:
https://eclipse.googlesource.com/jgit/jgit/+/6cc532a43cf28403cb623d3df8600a2542a40a43%5E%21/

A reverse index that is hot in RAM would obviously load in about 0ms.
But a cold load of a reverse index that uses only 4 bytes per object
(as Colby did here) for 3.1M objects could take ~590ms to read from
disk, assuming spinning media moving 20 MiB/s. If 8 byte offsets were
also stored this could be more like 1700ms.

Numbers obviously get better if the spinning media can transfer at 40
MiB/s, now its more like 295ms for 4 bytes/object and 885ms for 12
bytes/object.

I think its still reasonable to compute the reverse index on the fly.
But JGit certainly does have the benefit of reusing it across requests
by relying on process memory based caches. C Git needs to rely on the
kernel buffer cache, which requires this data be written out to a file
to be shared.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 1/4] contrib: add git-contacts helper

Junio C Hamano gits...@pobox.com writes:

  - If the patch were prepared with a non-standard src/dst-prefix,
unconditional substr($1, 2) would call blame on a wrong (and
likely to be nonexistent) path without a useful diagnosis (the
invocation of git blame will likely die with no such path
'tailofpathname' in $id).

One way to make it more robust may be to do something like this:

   if (/^--- /) {
   if (m{^--- (?:a/(.*)|/dev/null)$}) {
   $source = ($1 eq '/dev/null') ? undef : $1;

Typo/thinko.  I did that (?:(foo)|bar) thing so that I do not have
to do the conditional.  The above can just be

if (m{^--- (?:a/(.*)|/dev/null)$}) {
$source = $1;

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] t4205: replace .\+ with ..* in sed commands

Brian Gernhardt br...@gernhardtsoftware.com writes:

 OS X's sed only accepts basic regular expressions, which does not
 allow the + quantifier.  However '..*' (anything, followed by zero or
 more anything) is the same as '.\+' (one or more anything) and valid
 in any regular expression language.

Thanks for spotting this.

We shouldn't mark this as OS X's sed is broken, but as We try to
stick to POSIX BRE, and calling ERE elements via backslash escape,
e.g. \+, is a GNU extension we try to avoid.  Obviously we are not
always careful and sometimes these slip through the review process.


 Signed-off-by: Brian Gernhardt br...@gernhardtsoftware.com
 ---
  t/t4205-log-pretty-formats.sh | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
 index 719d132..3cfb744 100755
 --- a/t/t4205-log-pretty-formats.sh
 +++ b/t/t4205-log-pretty-formats.sh
 @@ -192,7 +192,7 @@ test_expect_success 'left alignment formatting with 
 trunc' 
  message ..
  message ..
  add bar  Z
 -$(commit_msg  8 .\+$)
 +$(commit_msg  8 ..*$)
  EOF
   test_cmp expected actual
  
 @@ -310,7 +310,7 @@ test_expect_success 'left/right alignment formatting with 
 stealing' 
  short long  long long
  message ..   A U Thor
  add bar  A U Thor
 -$(commit_msg  8 .\+$)   A U Thor
 +$(commit_msg  8 ..*$)   A U Thor
  EOF
   test_cmp expected actual
  
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] merge: handle --ff/--no-ff/--ff-only as a tri-state option

This has multiple benefits: with more than one of {--ff, --no-ff,
--ff-only} respects the last option; also the command-line option to
always take precedence over the config file option.

Signed-off-by: Miklos Vajna vmik...@suse.cz
---

On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty 
mhag...@alum.mit.edu wrote:
 If I find the time (unlikely) I might submit a patch to implement these
 expectations.

Seeing that the --no-ff / --ff-only combo wasn't denied just sort of 
accidently, I agree that it makes more sense to merge allow_fast_forward
and fast_forward_only to a single enum, that automatically gives you 
both benefits.

 builtin/merge.c  | 65 +---
 t/t7600-merge.sh | 12 ---
 2 files changed, 52 insertions(+), 25 deletions(-)

diff --git a/builtin/merge.c b/builtin/merge.c
index 2ebe732..561edf4 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -47,8 +47,8 @@ static const char * const builtin_merge_usage[] = {
 };
 
 static int show_diffstat = 1, shortlog_len = -1, squash;
-static int option_commit = 1, allow_fast_forward = 1;
-static int fast_forward_only, option_edit = -1;
+static int option_commit = 1;
+static int option_edit = -1;
 static int allow_trivial = 1, have_message, verify_signatures;
 static int overwrite_ignore = 1;
 static struct strbuf merge_msg = STRBUF_INIT;
@@ -76,6 +76,14 @@ static struct strategy all_strategy[] = {
 
 static const char *pull_twohead, *pull_octopus;
 
+enum ff_type {
+   FF_ALLOW,
+   FF_NO,
+   FF_ONLY
+};
+
+static enum ff_type fast_forward = FF_ALLOW;
+
 static int option_parse_message(const struct option *opt,
const char *arg, int unset)
 {
@@ -178,6 +186,21 @@ static int option_parse_n(const struct option *opt,
return 0;
 }
 
+static int option_parse_ff(const struct option *opt,
+ const char *arg, int unset)
+{
+   fast_forward = unset ? FF_NO : FF_ALLOW;
+   return 0;
+}
+
+static int option_parse_ff_only(const struct option *opt,
+ const char *arg, int unset)
+{
+   if (!unset)
+   fast_forward = FF_ONLY;
+   return 0;
+}
+
 static struct option builtin_merge_options[] = {
{ OPTION_CALLBACK, 'n', NULL, NULL, NULL,
N_(do not show a diffstat at the end of the merge),
@@ -194,10 +217,12 @@ static struct option builtin_merge_options[] = {
N_(perform a commit if the merge succeeds (default))),
OPT_BOOL('e', edit, option_edit,
N_(edit message before committing)),
-   OPT_BOOLEAN(0, ff, allow_fast_forward,
-   N_(allow fast-forward (default))),
-   OPT_BOOLEAN(0, ff-only, fast_forward_only,
-   N_(abort if fast-forward is not possible)),
+   { OPTION_CALLBACK, 0, ff, NULL, NULL,
+   N_(allow fast-forward (default)),
+   PARSE_OPT_NOARG, option_parse_ff },
+   { OPTION_CALLBACK, 0, ff-only, NULL, NULL,
+   N_(abort if fast-forward is not possible),
+   PARSE_OPT_NOARG, option_parse_ff_only },
OPT_RERERE_AUTOUPDATE(allow_rerere_auto),
OPT_BOOL(0, verify-signatures, verify_signatures,
N_(Verify that the named commit has a valid GPG signature)),
@@ -581,10 +606,9 @@ static int git_merge_config(const char *k, const char *v, 
void *cb)
else if (!strcmp(k, merge.ff)) {
int boolval = git_config_maybe_bool(k, v);
if (0 = boolval) {
-   allow_fast_forward = boolval;
+   fast_forward = boolval ? FF_ALLOW : FF_NO;
} else if (v  !strcmp(v, only)) {
-   allow_fast_forward = 1;
-   fast_forward_only = 1;
+   fast_forward = FF_ONLY;
} /* do not barf on values from future versions of git */
return 0;
} else if (!strcmp(k, merge.defaulttoupstream)) {
@@ -863,7 +887,7 @@ static int finish_automerge(struct commit *head,
 
free_commit_list(common);
parents = remoteheads;
-   if (!head_subsumed || !allow_fast_forward)
+   if (!head_subsumed || fast_forward == FF_NO)
commit_list_insert(head, parents);
strbuf_addch(merge_msg, '\n');
prepare_to_commit(remoteheads);
@@ -1008,7 +1032,7 @@ static void write_merge_state(struct commit_list 
*remoteheads)
if (fd  0)
die_errno(_(Could not open '%s' for writing), filename);
strbuf_reset(buf);
-   if (!allow_fast_forward)
+   if (fast_forward == FF_NO)
strbuf_addf(buf, no-ff);
if (write_in_full(fd, buf.buf, buf.len) != buf.len)
die_errno(_(Could not write to '%s'), filename);
@@ -1157,14 +1181,11 @@ int cmd_merge(int argc, const char **argv, const char 
*prefix)
show_diffstat = 0;
 
if (squash) {
-   if

Re: [PATCH] git-daemon: have --no-syslog

2013-07-01 Thread Andreas Krey

On Sat, 22 Jun 2013 23:21:03 +, Junio C Hamano wrote:
...
 Are there examples of other daemon programs outside Git that have
 this particular support to help such inetd implementations?

Unfortunately I only know one server that exclusively uses this
interface, and isn't even capable of running under inetd.

 I would like to know how widely this kind of workaround is done, and
 also what they call the option, as a quick sanity check.

The only open-source inetd-like server I know of that does this is Dan
Bernstein's tcpserver (which also passes the remote IP addresse and simile
in envvars), and it's probably more to the point to introduce
a --tcpserver in parallel to --inetd instead of doing --no-syslog.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] merge: handle --ff/--no-ff/--ff-only as a tri-state option

Miklos Vajna vmik...@suse.cz writes:

 On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty 
 mhag...@alum.mit.edu wrote:
 If I find the time (unlikely) I might submit a patch to implement these
 expectations.

 Seeing that the --no-ff / --ff-only combo wasn't denied just sort of 
 accidently, I agree that it makes more sense to merge allow_fast_forward
 and fast_forward_only to a single enum, that automatically gives you 
 both benefits.

Yes, this goes in the right direction.  Pick one out of these three
possibilities is how the configuration is done, and the command
line option parsing should follow suit by consolidating these two
variables into one.

Thanks, will queue.

I didn't read the patch carefully, though, so review comments are
very much appreciated.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFH] git reset --hard broken???

I have no time to dig this down, but I just noticed this by accident:

$ make
$ cd t
$ sh ./t7011-skip-worktree-reading.sh -d
$ cd trash*.t7011*
$ git reset --hard HEAD
error: Entry '1' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'HEAD'.

which looks quite bogus.  reset --hard is meant to be the last
resort no matter what, please match the working tree to the commit
and should not ever error out with not uptodate Cannot merge
message.

Interestingly, you can do this to work it around, though:

$ cd t
$ sh ./t7011-skip-worktree-reading.sh -d
$ cd trash*.t7011*
$ git reset
$ git reset --hard HEAD
HEAD is now at  init

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] git reset --hard broken???

On Mon, Jul 01, 2013 at 02:28:52PM -0700, Junio C Hamano wrote:

 I have no time to dig this down, but I just noticed this by accident:
 
   $ make
 $ cd t
 $ sh ./t7011-skip-worktree-reading.sh -d
 $ cd trash*.t7011*
 $ git reset --hard HEAD
 error: Entry '1' not uptodate. Cannot merge.
   fatal: Could not reset index file to revision 'HEAD'.
 
 which looks quite bogus.  reset --hard is meant to be the last
 resort no matter what, please match the working tree to the commit
 and should not ever error out with not uptodate Cannot merge
 message.

Yeah, I would agree. I do not think this is a new breakage. It behaves
the same way all the way back to v1.7.0 (the first commit with t7011).
Trying to go back further (by snapshotting the state of the trash
directory and just running the reset on it) doesn't work, as older
versions do not understand the skip-worktree bit.

I'm not sure yet if it's just a problem with skip-worktree entries, or
if you can trigger the problem another way, though.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] treat_directory(): do not declare submodules to be untracked

When the working tree walker encounters a directory, it asks the
function treat_directory() if it should descend into it, show it as
an untracked directory, or do something else.  When the directory is
the top of the submodule working tree, we used to say That is an
untracked directory, which was bogus.

It is an entity that is tracked in the index of the repository we
are looking at, and that is not to be descended into it.  Return
path_none, not path_untracked, to report that.

The existing case that path_untracked is returned for a newly
discovered submodule that is not tracked in the index (this only
happens when DIR_NO_GITLINKS option is not used) is unchanged, but
that is exactly because the submodule is not tracked in the index.

Signed-off-by: Junio C Hamano gits...@pobox.com
---
 dir.c   |  4 +---
 t/t3010-ls-files-killed-modified.sh | 23 ---
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/dir.c b/dir.c
index 897c874..0480419 100644
--- a/dir.c
+++ b/dir.c
@@ -1036,9 +1036,7 @@ static enum path_treatment treat_directory(struct 
dir_struct *dir,
return path_recurse;
 
case index_gitdir:
-   if (dir-flags  DIR_SHOW_OTHER_DIRECTORIES)
-   return path_none;
-   return path_untracked;
+   return path_none;
 
case index_nonexistent:
if (dir-flags  DIR_SHOW_OTHER_DIRECTORIES)
diff --git a/t/t3010-ls-files-killed-modified.sh 
b/t/t3010-ls-files-killed-modified.sh
index 262e617..f611d79 100755
--- a/t/t3010-ls-files-killed-modified.sh
+++ b/t/t3010-ls-files-killed-modified.sh
@@ -11,6 +11,8 @@ This test prepares the following in the cache:
 path1   - a symlink
 path2/file2 - a file in a directory
 path3/file3 - a file in a directory
+submod1/   - a submodule
+submod2/   - another submodule
 
 and the following on the filesystem:
 
@@ -21,9 +23,11 @@ and the following on the filesystem:
 path4  - a file
 path5  - a symlink
 path6/file6 - a file in a directory
+submod1/   - a submodule (modified from the cache)
+submod2/   - a submodule (matches the cache)
 
-git ls-files -k should report that existing filesystem
-objects except path4, path5 and path6/file6 to be killed.
+git ls-files -k should report that existing filesystem objects
+path0/*, path1/*, path2 and path3 to be killed.
 
 Also for modification test, the cache and working tree have:
 
@@ -33,7 +37,7 @@ Also for modification test, the cache and working tree have:
 path10 - a non-empty file, cache dirtied.
 
 We should report path0, path1, path2/file2, path3/file3, path7 and path8
-modified without reporting path9 and path10.
+modified without reporting path9 and path10.  submod1 is also modified.
 '
 . ./test-lib.sh
 
@@ -48,6 +52,18 @@ test_expect_success 'git update-index --add to add various 
paths.' '
: path9 
date path10 
git update-index --add -- path0 path?/file? path7 path8 path9 path10 
+   for i in 1 2
+   do
+   git init submod$i 
+   (
+   cd submod$i  git commit --allow-empty -m empty $i
+   ) || break
+   done 
+   git update-index --add submod[12]
+   (
+   cd submod1 
+   git commit --allow-empty -m empty 1 (updated)
+   ) 
rm -fr path?# leave path10 alone
 '
 
@@ -94,6 +110,7 @@ test_expect_success 'validate git ls-files -m output.' '
path3/file3
path7
path8
+   submod1
EOF
test_cmp .expected .output
 '
-- 
1.8.3.2-798-g923e168

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] Safety for stash save

The second patch is the real thing, but ls-files --killed needed
to be taught about submodules to avoid breaking stash save in a
repository with submodules, as the new safety uses it to detect what
will need to be killed (i.e. file D/F in the working tree getting
removed because we need to check out D as a file, or file D in the
working tree getting removed because we need to check out D/F as a
file) when reverting to the state in HEAD.

Junio C Hamano (1):
  treat_directory(): do not declare submodules to be untracked

Petr Baudis (1):
  git stash: avoid data loss when git stash save kills a directory

 Documentation/git-stash.txt | 12 ++--
 dir.c   |  4 +---
 git-stash.sh| 12 
 t/t3010-ls-files-killed-modified.sh | 23 ---
 t/t3903-stash.sh| 18 ++
 5 files changed, 61 insertions(+), 8 deletions(-)

-- 
1.8.3.2-798-g923e168

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] git stash: avoid data loss when git stash save kills a directory

From: Petr Baudis pa...@ucw.cz

stash save is about saving the local change to the working tree,
but also about restoring the state of the last commit to the working
tree.  When a local change is to turn a non-directory to a directory,
in order to restore the non-directory, everything in the directory
needs to be removed.

Which is fine when running git stash save --include-untracked,
but without that option, untracked, newly created files in the
directory will have to be discarded, if the state you are restoring
to has a non-directory at the same path as the directory.

Introduce a safety valve to fail the operation in such case, using
the ls-files --killed which was designed for this exact purpose.

The stash save is stopped when untracked files need to be
discarded because their leading path ceased to be a directory, and
the user is required to pass --force to really have the data
removed.

Signed-off-by: Petr Baudis pa...@ucw.cz
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 Documentation/git-stash.txt | 12 ++--
 git-stash.sh| 12 
 t/t3903-stash.sh| 18 ++
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index db7e803..7c8b648 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -14,7 +14,8 @@ SYNOPSIS
 'git stash' ( pop | apply ) [--index] [-q|--quiet] [stash]
 'git stash' branch branchname [stash]
 'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
-[-u|--include-untracked] [-a|--all] [message]]
+[-u|--include-untracked] [-a|--all] [-f|--force]
+[message]]
 'git stash' clear
 'git stash' create [message]
 'git stash' store [-m|--message message] [-q|--quiet] commit
@@ -44,7 +45,7 @@ is also possible).
 OPTIONS
 ---
 
-save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] 
[-q|--quiet] [message]::
+save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] 
[-q|--quiet] [-f|--force] [message]::
 
Save your local modifications to a new 'stash', and run `git reset
--hard` to revert them.  The message part is optional and gives
@@ -71,6 +72,13 @@ linkgit:git-add[1] to learn how to operate the `--patch` 
mode.
 +
 The `--patch` option implies `--keep-index`.  You can use
 `--no-keep-index` to override this.
++
+In some cases, saving a stash could mean irretrievably removing some
+data - if a directory with untracked files replaces a tracked file of
+the same name, the new untracked files are not saved (except in case
+of `--include-untracked`) but the original tracked file shall be restored.
+By default, `stash save` will abort in such a case; `--force` will allow
+it to remove the untracked files.
 
 list [options]::
 
diff --git a/git-stash.sh b/git-stash.sh
index 1e541a2..85c9e2c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -195,6 +195,7 @@ save_stash () {
keep_index=
patch_mode=
untracked=
+   force=
while test $# != 0
do
case $1 in
@@ -215,6 +216,9 @@ save_stash () {
-u|--include-untracked)
untracked=untracked
;;
+   -f|--force)
+   force=t
+   ;;
-a|--all)
untracked=all
;;
@@ -258,6 +262,14 @@ save_stash () {
say $(gettext No local changes to save)
exit 0
fi
+   if test -z $untracked$force 
+  test -n $(git ls-files --killed | head -n 1)
+   then
+   say $(gettext The following untracked files would NOT be 
saved but need to be removed by stash save:)
+   test -n $GIT_QUIET || git ls-files --killed | sed 's/^/\t/'
+   say $(gettext Aborting. Consider using either the --force or 
--include-untracked option.) 2
+   exit 1
+   fi
test -f $GIT_DIR/logs/$ref_stash ||
clear_stash || die $(gettext Cannot initialize stash)
 
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index debda7a..5d22f17 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -673,4 +673,22 @@ test_expect_success 'store updates stash ref and reflog' '
grep quux bazzy
 '
 
+test_expect_success 'stash a change to turn a non-directory to a directory' '
+   git reset --hard 
+   testfile 
+   git add testfile 
+   git commit -m add testfile as a regular file 
+   rm testfile 
+   mkdir testfile 
+   testfile/file 
+   test_must_fail git stash save recover regular file 
+   test -f testfile/file
+'
+
+test_expect_success 'stash a change to turn a non-directory to a directory 
(forced)' '
+   git stash save --force recover regular file (forced) 
+   ! test -f testfile/file 
+   test -f testfile
+'
+
 test_done
-- 
1.8.3.2-798-g923e168

--
To

Re: What's cooking in git.git (May 2013, #05; Mon, 20)

Johan Herland jo...@herland.net writes:

 On Tue, May 21, 2013 at 5:35 PM, Junio C Hamano gits...@pobox.com wrote:
 ... I think we can go either way, and the above I think this is
 being rerolld was primarily keeping the options open.

 You're right. No point in setting things prematurely in stone. I'll
 fold jh/shorten-refname into the ongoing series.

Ping?

No need to hurry, but just to make sure this didn't disappear from
everybody's radar.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] show-ref.c: Add missing call to git_config()

Ramsay Jones ram...@ramsay1.demon.co.uk writes:

 Yes, I will send a v2 (soon-ish, I hope).

Ping?

No need to hurry, but just to make sure this didn't disappear from
everybody's radar.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/5] allow more sources for config values

Heiko Voigt hvo...@hvoigt.net writes:

 This is only for review. I will resubmit this once 1.8.3 is out.

Ping?

No need to hurry, but just to make sure this didn't disappear from
everybody's radar.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Jun 2013, #01; Sun, 2)

Drew Northup n1xim.em...@gmail.com writes:

 On Sun, Jun 2, 2013 at 7:58 PM, Junio C Hamano gits...@pobox.com wrote:
 ...
 --
 [Stalled]
 ...
 * jk/gitweb-utf8 (2013-04-08) 4 commits
  - gitweb: Fix broken blob action parameters on blob/commitdiff pages
  - gitweb: Don't append ';js=(0|1)' to external links
  - gitweb: Make feed title valid utf8
  - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, 
 commitdiff_plain, and patch

  Various fixes to gitweb.

  Waiting for a reroll after a review.
  Will discard unless we hear from anybody who is interested in
  tying its loose ends.

 I'd like to have a closer look at these. It may be a week however as
 there's some serious in-house chaos going on right now. (Finally
 starting to settle after about 2 months...)

Ping?  No need to hurry but in case somebody else is interested but
is stopped because of this offer to review...

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] fast-import: handle empty paths better

John Keeping j...@keeping.me.uk writes:

 This series addressed Dave Abraham's recent bug report [1] about using
 fast-import's ls command with an empty path.  I also found a couple of
 other places that do not handle the empty path when it can reasonably be
 interpreted as meaning the root tree object, which are also fixed here.

 [1] http://article.gmane.org/gmane.comp.version-control.git/228586

 John Keeping (4):
   t9300: document fast-import empty path issues
   fast-import: set valid mode on root tree in ls
   fast-import: allow ls or filecopy of the root tree
   fast-import: allow moving the root tree

  fast-import.c  | 58 
  t/t9300-fast-import.sh | 65 
 ++
  2 files changed, 103 insertions(+), 20 deletions(-)

Ping?  Reviews, please?

No need to hurry, but just to make sure this didn't disappear from
everybody's radar.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (May 2013, #09; Wed, 29)

Jens Lehmann jens.lehm...@web.de writes:

 Am 02.06.2013 20:50, schrieb Junio C Hamano:
 Jens Lehmann jens.lehm...@web.de writes:
 
 Am 30.05.2013 01:58, schrieb Junio C Hamano:
 * jl/submodule-mv (2013-04-23) 5 commits
   (merged to 'next' on 2013-04-23 at c04f574)
  + submodule.c: duplicate real_path's return value
   (merged to 'next' on 2013-04-19 at 45ae3c9)
  + rm: delete .gitmodules entry of submodules removed from the work tree
  + Teach mv to update the path entry in .gitmodules for moved submodules
  + Teach mv to move submodules using a gitfile
  + Teach mv to move submodules together with their work trees

  git mv A B when moving a submodule A does the right thing,
  inclusing relocating its working tree and adjusting the paths in
  the .gitmodules file.

 detailed discussion snipped

 So my gut feeling of the fix at this point in the evolution of the
 program may be to error out with a message like You have local
 changes to .gitmodules; please stash it before moving or removing.

 Yeah, me too thinks that this is a sane short term solution (even
 though a git submodule add currently happily stages any unstaged
 modifications to the .gitmodules file too, that should not stop us
 from doing better for rm and mv ;-).

 And I also agree that in the long run the the git-config aware merge
 driver together with the 3-way merge of a modified .gitmodules file
 you described is the best solution. But I'd really like to complete
 the recursive update before tackling that, so for now I just added
 these two to the to-do list on my GitHub wiki page.

 I'll resubmit this series with the strlen() fix and the erroring out
 in case of unstaged modifications of the .gitmodules file as soon as
 I find some time.

Ping?

No need to hurry, but just to make sure this didn't disappear from
everybody's radar.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config

Michael Haggerty mhag...@alum.mit.edu writes:

 My understanding is that we are waiting on two things:

 1. Consensus from the community.  I would characterize the feedback on
 the mailing list as limited in quantity but strongly positive [1-4] and
 I think that most/all of the wishes for post-receive-email features that
 were originally omitted from git-multimail have been implemented in the
 current version.  Some of the mailing list feedback was about earlier
 versions.  Do you want people to give feedback specifically about the
 current version?

 2. For me to figure out what part of the git-multimail history I think
 should be included in the Git project, do any necessary repository
 rewriting, and submit a pull request to you.  The fact that I haven't
 gotten to this is due to the fact that I've been busy getting git-imerge
 [5] ready to present at GitMerge.

Ping, now GitMerge is over?

No need to hurry, but just to make sure this didn't disappear from
everybody's radar.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

repo.or.cz being not well???

Has something changed recently at repo.or.cz, accepting pushes over
ssh, in the past few days?  I am getting this:

$ git push -n -v repo.or.cz:srv/git/alt-git.git/
403 forbidden
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFH] Leftover bits

It is now in the middle of 5th week of this release cycle [*1*], and
due to the season being summer and with US holidays, I expect that
things will be more quiet than other weeks.  It was a good time to
review the recent issues of whats-cooking, and that is what I just
did.

Here is a list of topics, that I thought may be of merit, but
seem to be stalled for extensive timeperiod.

I am mostly worried about the ones that (superficially at least)
looked good to me but haven't got any reviews.


* jk/gitweb-utf8 (2013-04-08) 4 commits
 - gitweb: Fix broken blob action parameters on blob/commitdiff pages
 - gitweb: Don't append ';js=(0|1)' to external links
 - gitweb: Make feed title valid utf8
 - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, 
and patch

 Various fixes to gitweb.

 Drew Northup volunteered to take a look into this.
 $gmane/226216


* mg/more-textconv (2013-05-10) 7 commits
 - grep: honor --textconv for the case rev:path
 - grep: allow to use textconv filters
 - t7008: demonstrate behavior of grep with textconv
 - cat-file: do not die on --textconv without textconv filters
 - show: honor --textconv for blobs
 - diff_opt: track whether flags have been set explicitly
 - t4030: demonstrate behavior of show with textconv

 Make git grep and git show pay attention to --textconv when
 dealing with blob objects.

 I thought this was pretty well designed and executed, but it seems
 there are some doubts on the list; kicked back to 'pu'.


* jl/submodule-mv (2013-04-23) 5 commits
 - submodule.c: duplicate real_path's return value
 - rm: delete .gitmodules entry of submodules removed from the work tree
 - Teach mv to update the path entry in .gitmodules for moved submodules
 - Teach mv to move submodules using a gitfile
 - Teach mv to move submodules together with their work trees

 git mv A B when moving a submodule A does the right thing,
 inclusing relocating its working tree and adjusting the paths in
 the .gitmodules file.

 Waiting for a reroll.
 $gmane/226294


* hv/config-from-blob (2013-05-12) 5 commits
 - do not die when error in config parsing of buf occurs
 - teach config --blob option to parse config from database
 - config: make parsing stack struct independent from actual data source
 - config: drop cf validity check in get_next_char()
 - config: factor out config file stack management

 Waiting for a reroll.
 $gmane/223964


* rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits
 - ### DONTMERGE: needs better explanation on what config they need
 - pack-refs.c: Add missing call to git_config()
 - show-ref.c: Add missing call to git_config()

 The changes themselves are probably good, but it is unclear what
 basic setting needs to be read for which exact operation.

 Waiting for clarification.
 $gmane/228294


* jh/shorten-refname (2013-05-07) 4 commits
 - t1514: refname shortening is done after dereferencing symbolic refs
 - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin
 - t1514: Demonstrate failure to correctly shorten refs/remotes/origin/HEAD
 - t1514: Add tests of shortening refnames in strict/loose mode

 When remotes/origin/HEAD is not a symbolic ref, rev-parse
 --abbrev-ref remotes/origin/HEAD ought to show origin, not
 origin/HEAD, which is fixed with this series (if it is a symbolic
 ref that points at remotes/origin/something, then it should show
 origin/something and it already does).

 Expecting a reroll, as an early part of a larger series.
 $gmane/225137


* jk/fast-import-empty-ls (2013-06-23) 4 commits
 - fast-import: allow moving the root tree
 - fast-import: allow ls or filecopy of the root tree
 - fast-import: set valid mode on root tree in ls
 - t9300: document fast-import empty path issues

 Waiting for reviews.
 $gmane/228741


* mh/multimail (2013-04-21) 1 commit
 - git-multimail: a replacement for post-receive-email

 Waiting for the initial history to pull from.
 $gmane/223564


[Footnote]

*1* The release calendar is at http://tinyurl.com/gitCal
The 8th week is also expected to be slow due to OSCON.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: repo.or.cz being not well???

Junio C Hamano gits...@pobox.com writes:

 Has something changed recently at repo.or.cz, accepting pushes over
 ssh, in the past few days?  I am getting this:

 $ git push -n -v repo.or.cz:srv/git/alt-git.git/
 403 forbidden
 fatal: Could not read from remote repository.

 Please make sure you have the correct access rights
 and the repository exists.

Nevermind, I figured it out.

$ git push repo.or.cz:/srv/git/alt-git.git

seems to be the new way to spell the scp style push.

Two points to note, just in case it would help other users, are

 (1) The repository hierarchy is no longer under your initial
 directory and you have to explicitly ask for /srv/$path; and

 (2) You used to be able to, but no longer are allowed, to have a
 trailing slash in your repository URL.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

What's cooking in git.git (Jul 2013, #01; Mon, 1)

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

We are in the middle of 5th week now in the 11-week releace cycle
for 1.8.4, and quite a few topics have graduated to 'master'.
Please help ensure the quality of the upcoming release by testing
the tip of 'master' (and if you are so inclined, 'next') early.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to master]

* ap/diff-ignore-blank-lines (2013-06-19) 1 commit
  (merged to 'next' on 2013-06-23 at 9cf8e03)
 + diff: add --ignore-blank-lines option

 git diff learned a mode that ignores hunks whose change consists
 only of additions and removals of blank lines, which is the same as
 diff -B (ignore blank lines) of GNU diff.


* ap/rebase-multiple-fixups (2013-06-27) 1 commit
  (merged to 'next' on 2013-06-28 at c3d1b1e)
 + rebase -i: handle fixup! fixup! in --autosquash

 Having multiple fixup! on a line in the rebase instruction sheet
 did not work very well with git rebase -i --autosquash.


* ed/color-prompt (2013-06-26) 5 commits
  (merged to 'next' on 2013-06-28 at 334892c)
 + git-prompt.sh: add missing information in comments
 + git-prompt.sh: do not print duplicate clean color code
 + t9903: remove redundant tests
 + git-prompt.sh: refactor colored prompt code
 + t9903: add tests for git-prompt pcmode

 Code clean-up for in-prompt status script (in contrib/).


* ft/doc-git-transport (2013-06-26) 1 commit
  (merged to 'next' on 2013-06-27 at 4a7d248)
 + documentation: add git:// transport security notice


* jc/topo-author-date-sort (2013-06-21) 9 commits
  (merged to 'next' on 2013-06-26 at 9283719)
 + t6003: add --author-date-order test
 + topology tests: teach a helper to set author dates as well
 + t6003: add --date-order test
 + topology tests: teach a helper to take abbreviated timestamps
 + t/lib-t6000: style fixes
  (merged to 'next' on 2013-06-15 at ad4fb48)
 + log: --author-date-order
 + sort-in-topological-order: use prio-queue
 + prio-queue: priority queue of pointers to structs
 + toposort: rename lifo field
 (this branch uses jk/commit-info-slab; is tangled with jc/show-branch.)

 git log learned the --author-date-order option, with which the
 output is topologically sorted and commits in parallel histories
 are shown intermixed together based on the author timestamp.


* jk/commit-info-slab (2013-06-07) 3 commits
  (merged to 'next' on 2013-06-15 at 908ab93)
 + commit-slab: introduce a macro to define a slab for new type
 + commit-slab: avoid large realloc
 + commit: allow associating auxiliary info on-demand
 (this branch is used by jc/show-branch and jc/topo-author-date-sort.)

 Allow adding custom information to commit objects in order to
 represent unbound number of flag bits etc.


* jk/submodule-subdirectory-ok (2013-06-17) 6 commits
  (merged to 'next' on 2013-06-23 at f17fb37)
 + submodule: drop the top-level requirement
 + rev-parse: add --prefix option
 + submodule: show full path in error message
 + t7403: add missing  chaining
 + t7403: modernize style
 + t7401: make indentation consistent

 Allow various subcommands of git submodule to be run not from the
 top of the working tree of the superproject.


* kb/am-deprecate-resolved (2013-06-27) 1 commit
  (merged to 'next' on 2013-06-28 at 177f491)
 + am: replace uses of --resolved with --continue

 Promote git am --continue over git am --resolved for UI
 consistency.


* mh/loose-refs-race-with-pack-ref (2013-06-19) 3 commits
  (merged to 'next' on 2013-06-23 at 2099d0b)
 + resolve_ref_unsafe(): close race condition reading loose refs
 + resolve_ref_unsafe(): handle the case of an SHA-1 within loop
 + resolve_ref_unsafe(): extract function handle_missing_loose_ref()

 We read loose and packed rerferences in two steps, but after
 deciding to read a loose ref but before actually opening it to read
 it, another process racing with us can unlink it, which would cause
 us to barf. Update the codepath to retry when such a race is
 detected.


* mh/ref-races (2013-06-20) 11 commits
  (merged to 'next' on 2013-06-23 at 71f1a18)
 + for_each_ref: load all loose refs before packed refs
 + get_packed_ref_cache: reload packed-refs file when it changes
 + add a stat_validity struct
 + Extract a struct stat_data from cache_entry
 + packed_ref_cache: increment refcount when locked
 + do_for_each_entry(): increment the packed refs cache refcount
 + refs: manage lifetime of packed refs cache via reference counting
 + refs: implement simple transactions for the packed-refs file
 + refs: wrap the packed refs cache in a level of indirection
 + pack_refs(): split creation of packed refs and entry writing
 + repack_without_ref(): split list curation and entry writing
 (this branch is used by

Re: repo.or.cz being not well???

2013-07-01 Thread Andreas Schwab

Junio C Hamano gits...@pobox.com writes:

 Has something changed recently at repo.or.cz, accepting pushes over
 ssh, in the past few days?  I am getting this:

 $ git push -n -v repo.or.cz:srv/git/alt-git.git/
 403 forbidden
 fatal: Could not read from remote repository.

Seems like repo is being more picky about the exact path.  Have you
tried leaving off the trailing slash?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: repo.or.cz being not well???

2013-07-01 Thread Kyle McKay


My apologies.

repo.or.cz recently had some updates to support:

1) smart HTTP fetch
2) smart HTTP push (over https)
3) user removal of projects

Along with those updates it started doing more validation on paths.

I believe all the paths listed on http://repo.or.cz/w/alt-git.git are  
accepted as shown.


I was not previously aware that URLs not shown on that page were  
accepted, thank you for bringing it to my attention.


Do you feel that it's important to accept these alternate URL versions  
that are not listed on the project page:


1) Optional trailing '/'
2) For the ssh scp form, optional leading '/'

Regards,
Kyle

On Jul 1, 2013, at 15:21, Junio C Hamano wrote:

Junio C Hamano gits...@pobox.com writes:


Has something changed recently at repo.or.cz, accepting pushes over
ssh, in the past few days?  I am getting this:

   $ git push -n -v repo.or.cz:srv/git/alt-git.git/
   403 forbidden
   fatal: Could not read from remote repository.

   Please make sure you have the correct access rights
   and the repository exists.


Nevermind, I figured it out.

$ git push repo.or.cz:/srv/git/alt-git.git

seems to be the new way to spell the scp style push.

Two points to note, just in case it would help other users, are

(1) The repository hierarchy is no longer under your initial
directory and you have to explicitly ask for /srv/$path; and

(2) You used to be able to, but no longer are allowed, to have a
trailing slash in your repository URL.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 4/5] pretty: Add failing tests: --format output should honor logOutputEncoding

On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
 Am 6/26/2013 12:19, schrieb Alexey Shumkin:
  One can set an alias
  $ git config alias.lg log --graph --pretty=format:'%Cred%h%Creset
  -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%an%Creset'
  --abbrev-commit --date=local
  
  to see the log as a pretty tree (like *gitk* but in a terminal).
  
  However, log messages written in an encoding i18n.commitEncoding which 
  differs
  from terminal encoding are shown corrupted even when i18n.logOutputEncoding
  and terminal encoding are the same (e.g. log messages committed on a Cygwin 
  box
  with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and 
  vice versa).
  
  To simplify an example we can say the following two commands are expected
  to give the same output to a terminal:
  
  $ git log --oneline --no-color
  $ git log --pretty=format:'%h %s'
  
  However, the former pays attention to i18n.logOutputEncoding
  configuration, while the latter does not when it formats %s.
  
  The same corruption is true for
  $ git diff --submodule=log
  and
  $ git rev-list --pretty=format:%s HEAD
  and
  $ git reset --hard
  
  This patch adds failing tests for the next patch that fixes them.
  
  Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
 
  diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
  index 73ba5e8..6b62da2 100755
  --- a/t/t4205-log-pretty-formats.sh
  +++ b/t/t4205-log-pretty-formats.sh
 ...
  +commit_msg() {
  +   # String initial. initial partly in German (translated with Google 
  Translate),
  +   # encoded in UTF-8, used as a commit log message below.
  +   msg=$(printf initial. anf\303\244nglich)
  +   if test -n $1
  +   then
  +   msg=$(echo $msg | iconv -f utf-8 -t $1)
  +   fi
  +   if test -n $2 -a -n $3
  +   then
  +   # cut string, replace cut part with two dots
  +   # $2 - chars count from the beginning of the string
  +   # $3 - trailing chars
  +   # LC_ALL is set to make `sed` interpret . as a UTF-8 char not 
  a byte
  +   # as it does with C locale
  +   msg=$(echo $msg | LC_ALL=en_US.UTF-8 sed -e 
  s/^\(.\{$2\}\)$3/\1../)
 
 This does not work as expected on Windows because sed ignores the .UTF-8
 part of the locale specifier. (We don't even have en_US; we have de, but
 with de.UTF-8 this doesn't work, either.)
 
 I don't have an idea, yet, how to work it around.
 
Hmm. I have Cygwin v1.7 (on Windows 7 and Windows 2003 Server R2)
with many locales installed (and with en_US.UTF-8 locale, too)
Today I could not find a way to run tests with no en_US.UTF-8 locale 
installed simulation
to test your failure
  +   fi
  +   echo $msg
  +}
 
  -test_expect_success 'left alignment formatting with mtrunc' '
  -   git log --pretty=format:%(10,mtrunc)%s actual 
  +test_expect_failure 'left alignment formatting with mtrunc' 
  +   git log --pretty='format:%(10,mtrunc)%s' actual 
  # complete the incomplete line at the end
  echo actual 
  qz_to_tab_space \EOF expected 
   mess.. two
   mess.. one
   add bar  Z
  -initial  Z
  +$(commit_msg  4 .\{11\})
   EOF
  test_cmp expected actual
  -'
  +
 
 This is the failing test case.
Hmm, for me all these tests pass on both Linux and Cygwin (mentioned
above) boxes
 
 BTW, if you re-roll, there would be fewer changes needed if you kept the
 test code single-quoted, but changed \EOF to EOF where needed.
Yep, thanks for your correction

 
  diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
  index cc1008d..c66a07f 100755
  --- a/t/t6006-rev-list-format.sh
  +++ b/t/t6006-rev-list-format.sh
 ...
   test_expect_success 'setup' '
  : foo 
  git add foo 
  -   git commit -m added foo 
  +   git config i18n.commitEncoding iso-8859-1 
 
 Perhaps
   test_config i18n.commitEncoding iso-8859-1 
 
 Also, it is iso-8869-1 here, but we see iso8859-1 already used later.
 It's probably wise to use that same encoding name everywhere because we
 can be very sure that the latter is already understood on all supported
 platforms.
You're right (I've looked at explanation in
3994e8a98dc7bbf67e61d23c8125f44383499a1f; I've thought ISO-8859-1 is a
common name).
 
  +   git commit -m $added_iso88591 
  head1=$(git rev-parse --verify HEAD) 
  head1_short=$(git rev-parse --verify --short $head1) 
  tree1=$(git rev-parse --verify HEAD:) 
  tree1_short=$(git rev-parse --verify --short $tree1) 
  -   echo changed foo 
  -   git commit -a -m changed foo 
  +   echo $changed  foo 
  +   git commit -a -m $changed_iso88591 
  head2=$(git rev-parse --verify HEAD) 
  head2_short=$(git rev-parse --verify --short $head2) 
  tree2=$(git rev-parse --verify HEAD:) 
  tree2_short=$(git rev-parse --verify --short $tree2)
  +   git config --unset i18n.commitEncoding
   '
   
  -# usage: test_format name format_string expected_output
  +# usage: test_format

Re: repo.or.cz being not well???

Kyle McKay mack...@gmail.com writes:

 I was not previously aware that URLs not shown on that page were
 accepted, thank you for bringing it to my attention.

 Do you feel that it's important to accept these alternate URL versions
 that are not listed on the project page:

 1) Optional trailing '/'
 2) For the ssh scp form, optional leading '/'

I am on the fence.  As long as the accepted URL forms are advertised
clearly (which you guys do indeed do), I do not think there is much
reason to spend effort to loosen it again.  People can adjust.  On
the other hand, loosening _might_ reduce the cost of support calls
(like the one I just did) from long-time users.  I dunno.

I just (1) was curious, as getting error 403 when I didn't mean to
talk to an HTTP server was strange, and (2) wanted to make sure I am
talking with the same repo.or.cz without a funny MITM.  If I sounded
like complaining, that wasn't intended, and I am sorry.

Thanks for serving the community for all those years.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 2/5] t7102 (reset): don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
 t/t7102-reset.sh | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index df82ec9..05dfb27 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -192,7 +192,8 @@ test_expect_success \
'changing files and redo the last commit should succeed' '
echo 3rd line 2nd file secondfile 
git commit -a -C ORIG_HEAD 
-   check_changes 3d3b7be011a58ca0c179ae45d94e6c83c0b0cd0d 
+   head4=$(git rev-parse --verify HEAD) 
+   check_changes $head4 
test $(git rev-parse ORIG_HEAD) = \
$head5
 '
@@ -211,7 +212,7 @@ test_expect_success \
git reset --hard HEAD~2 
check_changes ddaefe00f1da16864591c61fdc7adb5d7cd6b74e 
test $(git rev-parse ORIG_HEAD) = \
-   3d3b7be011a58ca0c179ae45d94e6c83c0b0cd0d
+   $head4
 '
 
 .diff_expect
@@ -326,10 +327,11 @@ test_expect_success '--hard reset to HEAD should clear a 
failed merge' '
git checkout branch2 
echo 3rd line in branch2 secondfile 
git commit -a -m change in branch2 
+   head3=$(git rev-parse --verify HEAD) 
 
test_must_fail git pull . branch1 
git reset --hard 
-   check_changes 77abb337073fb4369a7ad69ff6f5ec0e4d6b54bb
+   check_changes $head3
 '
 
 .diff_expect
-- 
1.8.3.1.16.gce2c52e

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 1/5] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
 t/t6006-rev-list-format.sh | 140 +
 1 file changed, 77 insertions(+), 63 deletions(-)

diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 0393c9f..cc1008d 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -7,8 +7,19 @@ test_description='git rev-list --pretty=format test'
 
 test_tick
 test_expect_success 'setup' '
-touch foo  git add foo  git commit -m added foo 
-  echo changed foo  git commit -a -m changed foo
+   : foo 
+   git add foo 
+   git commit -m added foo 
+   head1=$(git rev-parse --verify HEAD) 
+   head1_short=$(git rev-parse --verify --short $head1) 
+   tree1=$(git rev-parse --verify HEAD:) 
+   tree1_short=$(git rev-parse --verify --short $tree1) 
+   echo changed foo 
+   git commit -a -m changed foo 
+   head2=$(git rev-parse --verify HEAD) 
+   head2_short=$(git rev-parse --verify --short $head2) 
+   tree2=$(git rev-parse --verify HEAD:) 
+   tree2_short=$(git rev-parse --verify --short $tree2)
 '
 
 # usage: test_format name format_string expected_output
@@ -32,49 +43,49 @@ has_no_color () {
test_cmp expect $1
 }
 
-test_format percent %%h 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format percent %%h EOF
+commit $head2
 %h
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
 %h
 EOF
 
-test_format hash %H%n%h 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-131a310eb913d107dd3c09a65d1651175898735d
-131a310
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cf
+test_format hash %H%n%h EOF
+commit $head2
+$head2
+$head2_short
+commit $head1
+$head1
+$head1_short
 EOF
 
-test_format tree %T%n%t 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-fe722612f26da5064c32ca3843aa154bdb0b08a0
-fe72261
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-4d5fcadc293a348e88f777dc0920f11e7d71441c
-4d5fcad
+test_format tree %T%n%t EOF
+commit $head2
+$tree2
+$tree2_short
+commit $head1
+$tree1
+$tree1_short
 EOF
 
-test_format parents %P%n%p 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cf
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format parents %P%n%p EOF
+commit $head2
+$head1
+$head1_short
+commit $head1
 
 
 EOF
 
 # we don't test relative here
-test_format author %an%n%ae%n%ad%n%aD%n%at 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format author %an%n%ae%n%ad%n%aD%n%at EOF
+commit $head2
 A U Thor
 aut...@example.com
 Thu Apr 7 15:13:13 2005 -0700
 Thu, 7 Apr 2005 15:13:13 -0700
 1112911993
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
 A U Thor
 aut...@example.com
 Thu Apr 7 15:13:13 2005 -0700
@@ -82,14 +93,14 @@ Thu, 7 Apr 2005 15:13:13 -0700
 1112911993
 EOF
 
-test_format committer %cn%n%ce%n%cd%n%cD%n%ct 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format committer %cn%n%ce%n%cd%n%cD%n%ct EOF
+commit $head2
 C O Mitter
 commit...@example.com
 Thu Apr 7 15:13:13 2005 -0700
 Thu, 7 Apr 2005 15:13:13 -0700
 1112911993
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
 C O Mitter
 commit...@example.com
 Thu Apr 7 15:13:13 2005 -0700
@@ -97,43 +108,43 @@ Thu, 7 Apr 2005 15:13:13 -0700
 1112911993
 EOF
 
-test_format encoding %e 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format encoding %e EOF
+commit $head2
+commit $head1
 EOF
 
-test_format subject %s 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format subject %s EOF
+commit $head2
 changed foo
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
 added foo
 EOF
 
-test_format body %b 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format body %b EOF
+commit $head2
+commit $head1
 EOF
 
-test_format raw-body %B 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format raw-body %B EOF
+commit $head2
 changed foo
 
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
 added foo
 
 EOF
 
-test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy EOF
+commit $head2
 [31mfoo[32mbar[34mbaz[mxyzzy
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
 [31mfoo[32mbar[34mbaz[mxyzzy
 EOF
 
-test_format advanced-colors '%C(red yellow bold)foo%C(reset)' 'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format advanced-colors '%C(red yellow bold)foo%C(reset)' EOF
+commit $head2
 [1;31;43mfoo[m
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
 [1;31;43mfoo[m
 EOF
 
@@ -186,39 +197,42 @@ This commit

[PATCH v8 0/5] Reroll patches against Git v1.8.3.2

v8 of this patch series includes the following changes against v7:
1. [PATCH v8 1/5] t6006 (rev-list-format): don't hardcode SHA-1 in expected 
outputs
untouched
2. [PATCH v8 2/5] t7102 (reset): don't hardcode SHA-1 in expected outputs
untouched
3. [PATCH v8 3/5] t4205 (log-pretty-formats): don't hardcode SHA-1 in expected 
outputs
untouched
4. [PATCH v8 4/5] pretty: Add failing tests: --format output should honor 
logOutputEncoding
Includes suggestions of Johannes Sixt:
iso-8859-1 encoding replaced with its more ancient synonym iso8859-1 
already used in tests
t/t6006-rev-list-format.sh:
   `test_format` function become simplier and more readable 
   `complex body`  `complex subject` tests are reverted back (to its 
initial state)
   2 tests added to test encoding conversions with i18n.commitEncoding unset
t/t7102-reset.sh:
   `commit_msg` function become more readable

5. [PATCH v8 5/5] pretty: --format output should honor logOutputEncoding 
untouched

P.S.
It's all started here 
[http://thread.gmane.org/gmane.comp.version-control.git/177634]

Alexey Shumkin (5):
  t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
  t7102 (reset): don't hardcode SHA-1 in expected outputs
  t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs
  pretty: Add failing tests: --format output should honor
logOutputEncoding
  pretty: --format output should honor logOutputEncoding

 builtin/reset.c  |   5 +-
 builtin/rev-list.c   |   1 +
 builtin/shortlog.c   |   1 +
 log-tree.c   |   1 +
 submodule.c  |   1 +
 t/t4041-diff-submodule-option.sh |  25 +++--
 t/t4205-log-pretty-formats.sh| 126 
 t/t6006-rev-list-format.sh   | 204 +--
 t/t7102-reset.sh |  39 +++-
 9 files changed, 270 insertions(+), 133 deletions(-)

-- 
1.8.3.1.16.gce2c52e

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 3/5] t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
 t/t4205-log-pretty-formats.sh | 48 +++
 1 file changed, 26 insertions(+), 22 deletions(-)

diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 26fbfde..73ba5e8 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -101,7 +101,11 @@ test_expect_failure 'NUL termination with --stat' '
 
 test_expect_success 'setup more commits' '
test_commit message one one one message-one 
-   test_commit message two two two message-two
+   test_commit message two two two message-two 
+   head1=$(git rev-parse --verify --short HEAD~0) 
+   head2=$(git rev-parse --verify --short HEAD~1) 
+   head3=$(git rev-parse --verify --short HEAD~2) 
+   head4=$(git rev-parse --verify --short HEAD~3)
 '
 
 test_expect_success 'left alignment formatting' '
@@ -117,18 +121,18 @@ EOF
test_cmp expected actual
 '
 
-test_expect_success 'left alignment formatting at the nth column' '
-   git log --pretty=format:%h %|(40)%s actual 
+test_expect_success 'left alignment formatting at the nth column' 
+   git log --pretty='format:%h %|(40)%s' actual 
# complete the incomplete line at the end
echo actual 
qz_to_tab_space \EOF expected 
-fa33ab1 message twoZ
-7cd6c63 message oneZ
-1711bf9 add barZ
-af20c06 initialZ
+$head1 message twoZ
+$head2 message oneZ
+$head3 add barZ
+$head4 initialZ
 EOF
test_cmp expected actual
-'
+
 
 test_expect_success 'left alignment formatting with no padding' '
git log --pretty=format:%(1)%s actual 
@@ -195,18 +199,18 @@ EOF
test_cmp expected actual
 '
 
-test_expect_success 'right alignment formatting at the nth column' '
-   git log --pretty=format:%h %|(40)%s actual 
+test_expect_success 'right alignment formatting at the nth column' 
+   git log --pretty='format:%h %|(40)%s' actual 
# complete the incomplete line at the end
echo actual 
qz_to_tab_space \EOF expected 
-fa33ab1  message two
-7cd6c63  message one
-1711bf9  add bar
-af20c06  initial
+$head1  message two
+$head2  message one
+$head3  add bar
+$head4  initial
 EOF
test_cmp expected actual
-'
+
 
 test_expect_success 'right alignment formatting with no padding' '
git log --pretty=format:%(1)%s actual 
@@ -234,18 +238,18 @@ EOF
test_cmp expected actual
 '
 
-test_expect_success 'center alignment formatting at the nth column' '
-   git log --pretty=format:%h %|(40)%s actual 
+test_expect_success 'center alignment formatting at the nth column' 
+   git log --pretty='format:%h %|(40)%s' actual 
# complete the incomplete line at the end
echo actual 
qz_to_tab_space \EOF expected 
-fa33ab1   message two  Z
-7cd6c63   message one  Z
-1711bf9 add barZ
-af20c06 initialZ
+$head1   message two  Z
+$head2   message one  Z
+$head3 add barZ
+$head4 initialZ
 EOF
test_cmp expected actual
-'
+
 
 test_expect_success 'center alignment formatting with no padding' '
git log --pretty=format:%(1)%s actual 
-- 
1.8.3.1.16.gce2c52e

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 5/5] pretty: --format output should honor logOutputEncoding

One can set an alias
$ git config [--global] alias.lg log --graph 
--pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%an%Creset'
--abbrev-commit --date=local

to see the log as a pretty tree (like *gitk* but in a terminal).

However, log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted even when i18n.logOutputEncoding
and terminal encoding are the same (e.g. log messages committed on a Cygwin box
with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice 
versa).

To simplify an example we can say the following two commands are expected
to give the same output to a terminal:

$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it formats %s.

The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
and
$ git reset --hard

This patch makes pretty --format honor logOutputEncoding when it formats
log message.

Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
 builtin/reset.c  |  5 -
 builtin/rev-list.c   |  1 +
 builtin/shortlog.c   |  1 +
 log-tree.c   |  1 +
 submodule.c  |  1 +
 t/t4041-diff-submodule-option.sh | 10 +-
 t/t4205-log-pretty-formats.sh| 34 +-
 t/t6006-rev-list-format.sh   |  8 
 t/t7102-reset.sh |  2 +-
 9 files changed, 35 insertions(+), 28 deletions(-)

diff --git a/builtin/reset.c b/builtin/reset.c
index 6032131..afa6e02 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -93,10 +93,12 @@ static int reset_index(const unsigned char *sha1, int 
reset_type, int quiet)
 static void print_new_head_line(struct commit *commit)
 {
const char *hex, *body;
+   char *msg;
 
hex = find_unique_abbrev(commit-object.sha1, DEFAULT_ABBREV);
printf(_(HEAD is now at %s), hex);
-   body = strstr(commit-buffer, \n\n);
+   msg = logmsg_reencode(commit, NULL, get_log_output_encoding());
+   body = strstr(msg, \n\n);
if (body) {
const char *eol;
size_t len;
@@ -107,6 +109,7 @@ static void print_new_head_line(struct commit *commit)
}
else
printf(\n);
+   logmsg_free(msg, commit);
 }
 
 static void update_index_from_diff(struct diff_queue_struct *q,
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 67701be..a5ec30d 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -111,6 +111,7 @@ static void show_commit(struct commit *commit, void *data)
ctx.date_mode = revs-date_mode;
ctx.date_mode_explicit = revs-date_mode_explicit;
ctx.fmt = revs-commit_format;
+   ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(ctx, commit, buf);
if (revs-graph) {
if (buf.len) {
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index 1fd6f8a..1434f8f 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -137,6 +137,7 @@ void shortlog_add_commit(struct shortlog *log, struct 
commit *commit)
ctx.subject = ;
ctx.after_subject = ;
ctx.date_mode = DATE_NORMAL;
+   ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(ctx, commit, ufbuf);
buffer = ufbuf.buf;
} else if (*buffer) {
diff --git a/log-tree.c b/log-tree.c
index 1946e9c..5277d3e 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -616,6 +616,7 @@ void show_log(struct rev_info *opt)
ctx.fmt = opt-commit_format;
ctx.mailmap = opt-mailmap;
ctx.color = opt-diffopt.use_color;
+   ctx.output_encoding = get_log_output_encoding();
pretty_print_commit(ctx, commit, msgbuf);
 
if (opt-add_signoff)
diff --git a/submodule.c b/submodule.c
index 1821a5b..78734e1 100644
--- a/submodule.c
+++ b/submodule.c
@@ -226,6 +226,7 @@ static void print_submodule_summary(struct rev_info *rev, 
FILE *f,
while ((commit = get_revision(rev))) {
struct pretty_print_context ctx = {0};
ctx.date_mode = rev-date_mode;
+   ctx.output_encoding = get_log_output_encoding();
strbuf_setlen(sb, 0);
strbuf_addstr(sb, line_prefix);
if (commit-object.flags  SYMMETRIC_LEFT) {
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index d300d0c..04348ea 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -94,7 +94,7 @@ test_expect_success 'diff.submodule does not affect plumbing' 
'
 commit_file sm1 
 head2=$(add_file sm1 foo3)
 
-test_expect_failure

[PATCH v8 4/5] pretty: Add failing tests: --format output should honor logOutputEncoding

One can set an alias
$ git config alias.lg log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%an%Creset'
--abbrev-commit --date=local

to see the log as a pretty tree (like *gitk* but in a terminal).

However, log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted even when i18n.logOutputEncoding
and terminal encoding are the same (e.g. log messages committed on a Cygwin box
with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice 
versa).

To simplify an example we can say the following two commands are expected
to give the same output to a terminal:

$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it formats %s.

The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
and
$ git reset --hard

This patch adds failing tests for the next patch that fixes them.

Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
 t/t4041-diff-submodule-option.sh |  35 ++
 t/t4205-log-pretty-formats.sh| 146 ---
 t/t6006-rev-list-format.sh   |  74 +++-
 t/t7102-reset.sh |  31 -
 4 files changed, 198 insertions(+), 88 deletions(-)

diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 32d4a60..d300d0c 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -1,6 +1,7 @@
 #!/bin/sh
 #
 # Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+# Copyright (c) 2013 Alexey Shumkin (+ non-UTF-8 commit encoding tests)
 #
 
 test_description='Support for verbose submodule differences in git diff
@@ -10,6 +11,9 @@ This test tries to verify the sanity of the --submodule 
option of git diff.
 
 . ./test-lib.sh
 
+# String added in German (translated with Google Translate), encoded in 
UTF-8,
+# used in sample commit log messages in add_file() function below.
+added=$(printf hinzugef\303\274gt)
 add_file () {
(
cd $1 
@@ -19,7 +23,8 @@ add_file () {
echo $name $name 
git add $name 
test_tick 
-   git commit -m Add $name || exit
+   msg_added_iso88591=$(echo Add $name ($added $name) | 
iconv -f utf-8 -t iso8859-1) 
+   git -c 'i18n.commitEncoding=iso8859-1' commit -m 
$msg_added_iso88591
done /dev/null 
git rev-parse --short --verify HEAD
)
@@ -89,29 +94,29 @@ test_expect_success 'diff.submodule does not affect 
plumbing' '
 commit_file sm1 
 head2=$(add_file sm1 foo3)
 
-test_expect_success 'modified submodule(forward)' '
+test_expect_failure 'modified submodule(forward)' '
git diff-index -p --submodule=log HEAD actual 
cat expected -EOF 
Submodule sm1 $head1..$head2:
-  Add foo3
+  Add foo3 ($added foo3)
EOF
test_cmp expected actual
 '
 
-test_expect_success 'modified submodule(forward)' '
+test_expect_failure 'modified submodule(forward)' '
git diff --submodule=log actual 
cat expected -EOF 
Submodule sm1 $head1..$head2:
-  Add foo3
+  Add foo3 ($added foo3)
EOF
test_cmp expected actual
 '
 
-test_expect_success 'modified submodule(forward) --submodule' '
+test_expect_failure 'modified submodule(forward) --submodule' '
git diff --submodule actual 
cat expected -EOF 
Submodule sm1 $head1..$head2:
-  Add foo3
+  Add foo3 ($added foo3)
EOF
test_cmp expected actual
 '
@@ -138,25 +143,25 @@ head3=$(
git rev-parse --short --verify HEAD
 )
 
-test_expect_success 'modified submodule(backward)' '
+test_expect_failure 'modified submodule(backward)' '
git diff-index -p --submodule=log HEAD actual 
cat expected -EOF 
Submodule sm1 $head2..$head3 (rewind):
-  Add foo3
-  Add foo2
+  Add foo3 ($added foo3)
+  Add foo2 ($added foo2)
EOF
test_cmp expected actual
 '
 
 head4=$(add_file sm1 foo4 foo5)
-test_expect_success 'modified submodule(backward and forward)' '
+test_expect_failure 'modified submodule(backward and forward)' '
git diff-index -p --submodule=log HEAD actual 
cat expected -EOF 
Submodule sm1 $head2...$head4:
-  Add foo5
-  Add foo4
-  Add foo3
-  Add foo2
+  Add foo5 ($added foo5)
+  Add foo4 ($added foo4)
+  Add foo3 ($added foo3)
+  Add foo2 ($added foo2)
EOF
test_cmp expected actual
 '
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 73ba5e8..a23da67

How to still kill git fetch with too many refs

2013-07-01 Thread Martin Fick

I have often reported problems with git fetch when there are 
many refs in a repo, and I have been pleasantly surprised 
how many problems I reported were so quickly fixed. :) With 
time, others have created various synthetic test cases to 
ensure that git can handle many many refs.  A simple 
synthetic test case with 1M refs all pointing to the same 
sha1 seems to be easily handled by git these days.  However, 
in our experience with our internal git repo, we still have 
performance issues related to having too many refs, in our 
kernel/msm instance we have around 400K.

When I tried the simple synthetic test case and could not 
reproduce bad results, so I tried something just a little 
more complex and was able to get atrocious results!!! 
Basically, I generate a packed-refs files with many refs 
which each point to a different sha1.  To get a list of 
valid but unique sha1s for the repo, I simply used rev-list.  
The result, a copy of linus' repo with a million unique 
valid refs and a git fetch of a single updated ref taking a 
very long time (55mins and it did not complete yet).  Note, 
with 100K refs it completes in about 2m40s.  It is likely 
not linear since 2m40s * 10 would be ~26m (but the 
difference could also just be how the data in the sha1s are 
ordered).


Here is my small reproducible test case for this issue:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cp -rp linux linux.1Mrefs-revlist

cd linux
echo Hello  hello ; git add hello ; git ci -a -m 'hello'
cd ..

cd linux.1Mrefs-revlist
git rev-list HEAD | for nn in $(seq 0 100) ; do for c in 
$(seq 0 1) ; do  read sha ; echo $sha refs/c/$nn/$c$nn ; 
done ; done  .git/packed-refs

time git fetch file:///$(dirname $PWD)/linux 
refs/heads/master

Any insights as to why it is so slow, and how we could 
possibly speed it up?

Thanks,

-Martin

PS: My tests were performed with git version 1.8.2.1 on 
linux 2.6.32-37-generic #81-Ubuntu SMP 


-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation
 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to still kill git fetch with too many refs

On Mon, Jul 01, 2013 at 09:02:31PM -0600, Martin Fick wrote:

 A simple synthetic test case with 1M refs all pointing to the same
 sha1 seems to be easily handled by git these days.  However, in our
 experience with our internal git repo, we still have performance
 issues related to having too many refs, in our kernel/msm instance we
 have around 400K.

I'm not too surprised. There's O(n^2) behavior in fetch-pack's
mark_complete function, as it adds each of the N ref tips to a
commit_list, sorting by date (so each insertion is O(n)).

I posted two alternative patches in May of 2011.  The first simply
avoids adding duplicate objects, which is simple and covers many
real-world cases (e.g., an alternates repository which has a bunch of
copies of the same tags, one per fork). The second one switches the
commit_list out for a heap-based priority queue.

We ended up taking the first (as ea5f220), since it was trivial and
obviously correct, but didn't bother with the second since:

  1. There had been no real-world reports of it.

  2. While in theory a priority queue implementation would be used in
 other spots, too, it ended up being a pain to use it, as most of
 the callers wanted list-like splicing.

You can see the original here:

  http://thread.gmane.org/gmane.comp.version-control.git/174003/focus=174005

Though it probably doesn't apply cleanly anymore.  However, I've kept it
rebased over the years at:

  git://github.com/peff/git.git jk/fast-commit-list

Junio recently added a priority queue implementation in b4b594a
(prio-queue: priority queue of pointers to structs, 2013-06-06), which
is currently in next. So a modern version of that series would build on
top of that, rather than my priority queue.

And yet another alternative would be to keep the list unsorted during
the mark_complete calls, and then sort it at the end. Like this:

diff --git a/fetch-pack.c b/fetch-pack.c
index abe5ffb..4df8abd 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -505,7 +505,7 @@ static int mark_complete(const char *refname, const 
unsigned char *sha1, int fla
struct commit *commit = (struct commit *)o;
if (!(commit-object.flags  COMPLETE)) {
commit-object.flags |= COMPLETE;
-   commit_list_insert_by_date(commit, complete);
+   commit_list_insert(commit, complete);
}
}
return 0;
@@ -622,6 +622,7 @@ static int everything_local(struct fetch_pack_args *args,
if (!args-depth) {
for_each_ref(mark_complete, NULL);
for_each_alternate_ref(mark_alternate_complete, NULL);
+   commit_list_sort_by_date(complete);
if (cutoff)
mark_recent_complete_commits(args, cutoff);
}

(If you're wondering why we didn't do this trivial bit at the time, it
was because back then we did not yet have the René's nice linked-list
mergesort that backs commit_list_sort_by_date).

 The result, a copy of linus' repo with a million unique 
 valid refs and a git fetch of a single updated ref taking a 
 very long time (55mins and it did not complete yet).  Note, 
 with 100K refs it completes in about 2m40s.  It is likely 
 not linear since 2m40s * 10 would be ~26m (but the 
 difference could also just be how the data in the sha1s are 
 ordered).

That sounds like the O(n^2) problem. My timings back then with 100K refs
were 1-2 minutes. Does the patch above fix it for you?

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to still kill git fetch with too many refs

On Tue, Jul 02, 2013 at 12:07:58AM -0400, Jeff King wrote:

 And yet another alternative would be to keep the list unsorted during
 the mark_complete calls, and then sort it at the end. Like this:

Amusingly, I seem to have posted the exact same patch last year:

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

but never polished it up. It does cut a little time off of the initial
ref-loading that fetch-pack does (especially when we do not end up
transferring any objects at all). But it does not solve your problem.

I replicated your test setup, and the problem is that we have many
common objects on both sides during the ref negotiation. So we end up in
rev_list_push for each one, which has the same O(n^2) behavior.
Switching it to just sort at the end is not trivial; we first insert all
of the objects, but then we actually walk the parents, pushing onto the
list as we go. So I think we'd want a better data structure (like a
priority queue).

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to still kill git fetch with too many refs

On Tue, Jul 02, 2013 at 12:41:51AM -0400, Jeff King wrote:

 I replicated your test setup, and the problem is that we have many
 common objects on both sides during the ref negotiation. So we end up in
 rev_list_push for each one, which has the same O(n^2) behavior.
 Switching it to just sort at the end is not trivial; we first insert all
 of the objects, but then we actually walk the parents, pushing onto the
 list as we go. So I think we'd want a better data structure (like a
 priority queue).

Like the patch below, which is built on top of next (which has Junio's
prio_queue implementation), and has both the priority queue fix for
rev_list_push and the mark_complete sort-at-the-end fix. With this, your
test case completes in a few seconds (no clue if it would ever have
finished otherwise; I never let it run for more than a minute or two,
but I did confirm that it was spending all of its time in
commit_list_insert_by_date).

I didn't look too hard at the actual semantics, so there might be away
to not mark so many commits in the first place. This is just a mindless
replacement of an O(n^2) list insertion with the queue.

I did note two oddities, though:

  1. In the original, we never free the commit_list pointers when we pop
 them (or when we clear the list in find_common. So I think the
 existing code was leaking memory, and my version does not.

  2. In the original version of get_rev, we peek at the head commit of
 rev_list:

   commit = rev_list-item;

 Then we look at the parents of that commit, and possibly push them
 onto rev_list:

   while (parents) {
  if (!(parents-item-object.flags  SEEN))
  rev_list_push(parents-item, mark);
  ...
   }

 and then finally, pop the commit off the list:

   rev_list = rev_list-next;

 But what guarantee do we have that the commit we just processed is
 still at the front of the list? If the timestamps are monotonic,
 then the parent must come after the descendent and therefore will
 not have gotten pushed onto the front of the list. But in the face
 of clock skew, this is not the case, and we will have just skipped
 over the parent with our pop.

 So unless I am missing something very clever, I think this was a
 bug (albeit a difficult one to have matter). And it's also fixed by
 using prio_queue (which does the peek/pop together at the top of
 the function).

diff --git a/commit.c b/commit.c
index 521e49c..ebc0eea 100644
--- a/commit.c
+++ b/commit.c
@@ -581,7 +581,7 @@ static int compare_commits_by_author_date(const void *a_, 
const void *b_,
return 0;
 }
 
-static int compare_commits_by_commit_date(const void *a_, const void *b_, void 
*unused)
+int compare_commits_by_commit_date(const void *a_, const void *b_, void 
*unused)
 {
const struct commit *a = a_, *b = b_;
/* newer commits with larger date first */
diff --git a/commit.h b/commit.h
index 4d452dc..18a5234 100644
--- a/commit.h
+++ b/commit.h
@@ -254,4 +254,6 @@ extern void check_commit_signature(const struct commit* 
commit, struct signature
  */
 extern void check_commit_signature(const struct commit* commit, struct 
signature_check *sigc);
 
+int compare_commits_by_commit_date(const void *a_, const void *b_, void 
*unused);
+
 #endif /* COMMIT_H */
diff --git a/fetch-pack.c b/fetch-pack.c
index abe5ffb..6684348 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -11,6 +11,7 @@
 #include run-command.h
 #include transport.h
 #include version.h
+#include prio-queue.h
 
 static int transfer_unpack_limit = -1;
 static int fetch_unpack_limit = -1;
@@ -37,7 +38,7 @@ static int marked;
  */
 #define MAX_IN_VAIN 256
 
-static struct commit_list *rev_list;
+static struct prio_queue rev_list = { compare_commits_by_commit_date };
 static int non_common_revs, multi_ack, use_sideband, allow_tip_sha1_in_want;
 
 static void rev_list_push(struct commit *commit, int mark)
@@ -49,7 +50,7 @@ static void rev_list_push(struct commit *commit, int mark)
if (parse_commit(commit))
return;
 
-   commit_list_insert_by_date(commit, rev_list);
+   prio_queue_put(rev_list, commit);
 
if (!(commit-object.flags  COMMON))
non_common_revs++;
@@ -122,10 +123,10 @@ static const unsigned char *get_rev(void)
unsigned int mark;
struct commit_list *parents;
 
-   if (rev_list == NULL || non_common_revs == 0)
+   if (rev_list.nr == 0 || non_common_revs == 0)
return NULL;
 
-   commit = rev_list-item;
+   commit = prio_queue_get(rev_list);
if (!commit-object.parsed)
parse_commit(commit);
parents = commit-parents;
@@ -152,8 +153,6 @@ static const unsigned char

[PATCH 1/2] t1512: correct leftover constants from earlier edition

The earliest iteration of this test script used a magic string
110282 as the common prefix for ambiguous object names, but the
final edition switched the common prefix to 00 (10 0s).

Unfortunately, instances of the original prefix were left in the
comments and a few tests.  Replace them with the correct constants.

Signed-off-by: Junio C Hamano gits...@pobox.com
---
 t/t1512-rev-parse-disambiguation.sh | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/t/t1512-rev-parse-disambiguation.sh 
b/t/t1512-rev-parse-disambiguation.sh
index 6b3d797..5b58e4f 100755
--- a/t/t1512-rev-parse-disambiguation.sh
+++ b/t/t1512-rev-parse-disambiguation.sh
@@ -77,6 +77,7 @@ test_expect_success 'disambiguate blob' '
 
 test_expect_success 'disambiguate tree' '
commit=$(echo d7xm | git commit-tree 0) 
+   # this commit is f2e and not ambiguous with the 0* objects
test $(git rev-parse $commit^{tree}) = $(git rev-parse 00cdc)
 '
 
@@ -99,10 +100,14 @@ test_expect_success 'disambiguate commit-ish' '
 
 test_expect_success 'disambiguate commit' '
commit=$(echo hoaxj | git commit-tree 00cdc -p 0) 
+   # this commit is ffd8 and not ambiguous with the 0* objects
test $(git rev-parse $commit^) = $(git rev-parse 00e4f)
 '
 
 test_expect_success 'log name1..name2 takes only commit-ishes on both ends' '
+   # These are underspecified from the prefix-length point of view
+   # to disambiguate the commit with other objects, but there is only
+   # one commit that has 0* prefix at this point.
git log 0..0 
git log ..0 
git log 0.. 
@@ -112,16 +117,19 @@ test_expect_success 'log name1..name2 takes only 
commit-ishes on both ends' '
 '
 
 test_expect_success 'rev-parse name1..name2 takes only commit-ishes on both 
ends' '
+   # Likewise.
git rev-parse 0..0 
git rev-parse ..0 
git rev-parse 0..
 '
 
 test_expect_success 'git log takes only commit-ish' '
+   # Likewise.
git log 0
 '
 
 test_expect_success 'git reset takes only commit-ish' '
+   # Likewise.
git reset 0
 '
 
@@ -131,26 +139,30 @@ test_expect_success 'first tag' '
 '
 
 test_expect_failure 'two semi-ambiguous commit-ish' '
+   # At this point, we have a tag 00f8f that points
+   # at a commit 00e4f, and a tree and a blob that
+   # share 00 prefix with these tag and commit.
+   #
# Once the parser becomes ultra-smart, it could notice that
-   # 110282 before ^{commit} name many different objects, but
+   # 00 before ^{commit} name many different objects, but
# that only two (HEAD and v1.0.0 tag) can be peeled to commit,
# and that peeling them down to commit yield the same commit
# without ambiguity.
-   git rev-parse --verify 110282^{commit} 
+   git rev-parse --verify 00^{commit} 
 
# likewise
-   git log 0..0 
-   git log ..0 
-   git log 0.. 
-   git log 0...0 
-   git log ...0 
-   git log 0...
+   git log 00..00 
+   git log ..00 
+   git log 00.. 
+   git log 00...00 
+   git log ...00 
+   git log 00...
 '
 
 test_expect_failure 'three semi-ambiguous tree-ish' '
# Likewise for tree-ish.  HEAD, v1.0.0 and HEAD^{tree} share
# the prefix but peeling them to tree yields the same thing
-   git rev-parse --verify 0^{tree}
+   git rev-parse --verify 00^{tree}
 '
 
 test_expect_success 'parse describe name' '
@@ -241,7 +253,7 @@ test_expect_success 'ambiguous commit-ish' '
# Now there are many commits that begin with the
# common prefix, none of these should pick one at
# random.  They all should result in ambiguity errors.
-   test_must_fail git rev-parse --verify 110282^{commit} 
+   test_must_fail git rev-parse --verify ^{commit} 
 
# likewise
test_must_fail git log 0..0 
-- 
1.8.3.2-795-g615e8f0

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] Fix t1512 (disambiguation of object names)

Here is a small two-patch series to break a test that has been
passing by mistake.

Junio C Hamano (2):
  t1512: correct leftover constants from earlier edition
  get_short_sha1(): correctly disambiguate type-limited abbreviation

 sha1_name.c |  2 +-
 t/t1512-rev-parse-disambiguation.sh | 32 ++--
 2 files changed, 23 insertions(+), 11 deletions(-)

-- 
1.8.3.2-795-g615e8f0

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] get_short_sha1(): correctly disambiguate type-limited abbreviation

One test in t1512 that expects a failure incorrectly passed.  The
test prepares a commit whose object name begins with ten 0s, and
also prepares a tag that points at the commit.  The object name of
the tag also begins with ten 0s.  There is no other commit-ish
object in the repository whose name begins with such a prefix.

Ideally, in such a repository:

$ git rev-parse --verify 00^{commit}

should yield that commit.  If 00 is taken as the commit
00e4f, peeling it to a commmit yields that commit itself,
and if 00 is taken as the tag 00f8f, peeling it to a
commit also yields the same commit, so in that twisted sense, the
extended SHA-1 expression 00^{commit} is unambigous.  The
test that expects a failure is to check the above command.

The reason the test expects a failure is that we did not implement
such a unification of two candidate objects.  What we did (or at
least, meant to) implement was to recognise that a commit-ish is
required to expand 00, and notice that there are two succh
commit-ish, and diagnose the request as ambiguous.

However, there was a bug in the logic to check the candidate
objects.  When the code saw 00f8f (a tag) that shared the
shortened prefix (ten 0s), it tried to make sure that the tag is a
commit-ish by looking at the tag object.  Because it incorrectly
used lookup_object() when the tag has not been parsed, however, we
incorrectly declared that the tag is _not_ a commit-ish, leaving the
sole commit in the repository, 00e4f, that has the required
prefix as unique match, causing the test to pass when it shouldn't.

This fixes the logic to inspect the type of the object a tag refers
to, to make the test that is expected to fail correctly fail.

Signed-off-by: Junio C Hamano gits...@pobox.com
---
 sha1_name.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sha1_name.c b/sha1_name.c
index 8bc20c5..13c3d75 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -241,7 +241,7 @@ static int disambiguate_committish_only(const unsigned char 
*sha1, void *cb_data
return 0;
 
/* We need to do this the hard way... */
-   obj = deref_tag(lookup_object(sha1), NULL, 0);
+   obj = deref_tag(parse_object(sha1), NULL, 0);
if (obj  obj-type == OBJ_COMMIT)
return 1;
return 0;
-- 
1.8.3.2-795-g615e8f0

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to still kill git fetch with too many refs

Jeff King p...@peff.net writes:

 On Tue, Jul 02, 2013 at 12:41:51AM -0400, Jeff King wrote:

 I replicated your test setup, and the problem is that we have many
 common objects on both sides during the ref negotiation. So we end up in
 rev_list_push for each one, which has the same O(n^2) behavior.
 Switching it to just sort at the end is not trivial; we first insert all
 of the objects, but then we actually walk the parents, pushing onto the
 list as we go. So I think we'd want a better data structure (like a
 priority queue).

 Like the patch below, which is built on top of next (which has Junio's
 prio_queue implementation), and has both the priority queue fix for
 rev_list_push and the mark_complete sort-at-the-end fix.

Wow, I saw 160 lines in my MUA which scared me a bit until I
opened it to realize 40% is discussion and most of the remaining
lines are context around single liners.

It just looks too easy/simple, but the result looks correct, at
least from a cursory read.

Good job ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to still kill git fetch with too many refs