Regarding download of one *.git repository

[Shraddha Shardul Desai]

Dear Sir,
   I want to get RAxML source from
https://github.com/stamatak/RAxML-Light-1.0.5.git.
   I have installed git utility on my linux.
   What I need to do to download source of RAxML with help of GIT.

Regards,
Shraddha S.Desai
Senior Technical Engineer, HPC Solutions Group
C-DAC R&D,Pune
Phone  : +91 20 25514540
E-Mail : shradd...@cdac.in
Website: www.cdac.in



---

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

--
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

git-svn fetch shows merge-base help

[Piotr Krukowiecki]

Hi,

sometimes when I do git-svn fetch I get following:

usage: git merge-base [-a|--all]  ...
   or: git merge-base [-a|--all] --octopus ...
   or: git merge-base --independent ...

-a, --all output all common ancestors
--octopus find ancestors for a single n-way merge
--independent list revs not reachable from others

W: Cannot find common ancestor between  and
e928383b6c16ef5a562f8c6f29d5568330c6b307. Ignoring merge info.
usage: git merge-base [-a|--all]  ...
   or: git merge-base [-a|--all] --octopus ...
   or: git merge-base --independent ...

-a, --all output all common ancestors
--octopus find ancestors for a single n-way merge
--independent list revs not reachable from others

W: Cannot find common ancestor between  and
6112c8ea3e8352d8c7511064faf013116e8a383e. Ignoring merge info.

[repeated several times]

r228807 = c70f12894de2e3278a8cf534f565cbf11533c170
(refs/remotes/tags/)

$ git --version
git version 1.7.11.1.104.ge7b44f1

-- 
Piotr Krukowiecki
--
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: On using receive.denyNonFastForwards and advice.pushNonFastForward

[Matthieu Moy]

Hilco Wijbenga  writes:

> I was wondering how hard it would be to make "git push" more adamant
> about not pushing non-ff updates. So I wanted to see the effects of
> receive.denyNonFastForwards

This changes the behavior only if you use --force (or some magic refspec
starting with +). If you never used --force or +refspecs, you never did
a non-fast-forward push.

> and advice.pushNonFastForward.

Activated by default, so if you never did anything about it, it was
already active.

> Apparently, linear history and FF-only updates are not the same thing?

No, they are not. non-FF means you're trying to push a commit which is
not a direct descendant of the remote one, i.e. you're trying to
override the remote history with yours. See 'NOTE ABOUT FAST-FORWARDS'
in "man git-push".

-- 
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: [PATCH 2/2] git p4: add support for 'p4 move' in P4Submit

[Pete Wyckoff]

gits...@pobox.com wrote on Thu, 05 Jul 2012 23:28 -0700:
> Pete Wyckoff  writes:
> 
> > diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
> > index 84fffb3..8be74b6 100755
> > --- a/t/t9814-git-p4-rename.sh
> > +++ b/t/t9814-git-p4-rename.sh
> > @@ -77,16 +77,16 @@ test_expect_success 'detect renames' '
> > git commit -a -m "Rename file1 to file4" &&
> > git diff-tree -r -M HEAD &&
> > git p4 submit &&
> > -   p4 filelog //depot/file4 &&
> > -   p4 filelog //depot/file4 | test_must_fail grep -q "branch from" 
> > &&
> > +   p4 filelog //depot/file4 | tee filelog &&
> > +   ! grep -q " from //depot" filelog &&
> 
> I am not a huge fan of using "tee" in our test scripts, especially
> as it means piping output of another command whose output (and
> presumably the behaviour) we care about, hiding its exit status.
> 
> Fixing the incorrect use of piping to "test_must_fail grep" is a
> good change, but is there anything wrong to do the above like this?
> 
>   p4 filelog //depot/file4 >filelog &&
>   ! grep -q " from //depot" filelog &&

I'd started growing fond of "tee" as it shows all the
output, and isolates the grep as a separate step.  Much
easier to see the bad output when a test fails.

I'll switch around to your approach, adding a "cat filelog" line
for interesting cases.

-- Pete

--
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

Git and Quilt

[Jimmy Thrasibule]

Hello,

I have a core project on which I maintain a set of patches using Quilt.
This allows me to make changes to the project without touching the files
so I can upgrade to new versions easily.

I keep my patches and the core project in a Git repository. When I want
to change something, I apply my patches using Quilt, then I revert all
my changes and I just commit the resulting patch.

I would like to have a branch where all my patches are applied to deploy
the code but I can't find any good way to do this.

If I create a new branch from master and apply the patches, I will have
conflicts on the next merge. I need something to apply the patches
before the merge (maybe using one of the hooks?).

Any idea?

--
Jimmy


--
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 and Quilt

[Konstantin Khomoutov]

On Mon, 09 Jul 2012 13:57:09 +0200
Jimmy Thrasibule  wrote:

> I have a core project on which I maintain a set of patches using
> Quilt. This allows me to make changes to the project without touching
> the files so I can upgrade to new versions easily.
> 
> I keep my patches and the core project in a Git repository. When I
> want to change something, I apply my patches using Quilt, then I
> revert all my changes and I just commit the resulting patch.
> 
> I would like to have a branch where all my patches are applied to
> deploy the code but I can't find any good way to do this.
> 
> If I create a new branch from master and apply the patches, I will
> have conflicts on the next merge. I need something to apply the
> patches before the merge (maybe using one of the hooks?).

Isn't what you're doing a perfect fit for rebasing [1]?
That is, you keep your changes as a series of commits on top of your
"upstream" branch and each time you're about to bring upstream changes
in, you rebase your local branch on top on the updated upstream branch.

1. http://git-scm.com/book/en/Git-Branching-Rebasing
--
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

Student project in Ensimag: thanks all!

[Matthieu Moy]

Hi,

For the third year, I offered my students to contribute to open-source
software as part of a school project. This year, we had one team on the
core of Git (who implemented better advices for "git status", the XDG
configuration directory, and "git rebase -i --exec"), and two working on
the Git-mediawiki interface (one worked on new features like support for
mediafiles and authentication using the git credentials mechanism, and
another on an automated testsuite).

The project itself ended a while ago, but some of the patch series
needed extra care to end up in pu. This is now done :-).

A few series have been abandoned ("bisect old/new", and "warn before
rebase/commit"), I've added pointers to the gmane threads on the page
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
in case someone wants to continue the work.

To conclude the project, I would like to thank everybody for their
participation: the students for their hard work, reviewers for their
support and patience, and of course Junio for being such a good
maintainer!

Looking forward to next years' project!

-- 
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: Git and Quilt

[Jimmy Thrasibule]

> Isn't what you're doing a perfect fit for rebasing [1]?
> That is, you keep your changes as a series of commits on top of your
> "upstream" branch and each time you're about to bring upstream changes
> in, you rebase your local branch on top on the updated upstream branch.
> 
> 1. http://git-scm.com/book/en/Git-Branching-Rebasing

Yes it can do the work, but I afraid that it gets messy in a
collaborative work as said at the end of the article. I prefer to
maintain my patches using Quilt so everything is clear.

--
Jimmy

--
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: Regarding download of one *.git repository

[jaseem abid]

On Mon, Jul 9, 2012 at 12:25 PM, Shraddha Shardul Desai
 wrote:
>
> Dear Sir,
>I want to get RAxML source from
> https://github.com/stamatak/RAxML-Light-1.0.5.git.
>I have installed git utility on my linux.
>What I need to do to download source of RAxML with help of GIT.

$ git clone git://github.com/stamatak/RAxML-Light-1.0.5.git

I would suggest some reading on git. Progit [1] is a great book for
learning more.

1 :  http://git-scm.com/book


--
Jaseem Abid
http://jaseemabid.github.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

Using git commit --amend on a commit with an empty message

[Chris Webb]

Github gists can be cloned as normal git repositories, but the commits made
through the web interface appear with an empty commit message. Running
git commit --amend against them exposes a slightly odd behaviour of git,
which I can also demonstrate as follows:

  $ git init foo && cd foo
  $ touch one && git add one
  $ git commit -m '' --allow-empty-message
  [master (root-commit) 535cb36] 
   0 files changed
   create mode 100644 one

When I try to correct this commit message in an editor, it refuses to
proceed, objecting to the existing empty commit message:

  $ git commit --amend
  fatal: commit has empty message

Shouldn't this drop me into the editor and fail only if the resulting
message on exit is empty? (For comparison, git commit --amend -m 'oops' will
work fine; it's apparently only the edit case which doesn't.)

In fact, we even fail to start the editor if --allow-empty-message is
explicitly provided:

  $ git commit --amend --allow-empty-message
  fatal: commit has empty message

Assuming this isn't intentional for some reason I don't understand, I think
this is the correct tiny fix? make test succeeds fine both before and after.

-- >8 --
Subject: [PATCH] Allow edit of empty message with commit --amend

If git commit --amend is used on a commit with an empty message, it fails
unless -m is given, whether or not --allow-empty-message is specified.

Instead, allow it to proceed to the editor with an empty commit message.
Unless --allow-empty-message is in force, it will still abort later if an
empty message is saved from the editor. (That check was already present
and necessary to prevent a non-empty commit message being edited to an
empty one.)

Signed-off-by: Chris Webb 
---
 builtin/commit.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index f43eaaf..6515da2 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -640,7 +640,7 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
hook_arg1 = "message";
} else if (use_message) {
buffer = strstr(use_message_buffer, "\n\n");
-   if (!buffer || buffer[2] == '\0')
+   if (!use_editor && (!buffer || buffer[2] == '\0'))
die(_("commit has empty message"));
strbuf_add(&sb, buffer + 2, strlen(buffer + 2));
hook_arg1 = "commit";
-- 
1.7.10

--
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 v2 1/2] test: git-stash conflict sets up rerere

[Phil Hord]

Junio C Hamano  wrote:
> Phil Hord  writes:
>
> > Add a failing test to confirm a conflicted stash apply invokes
> > rerere to record the conflicts and resolve the the files it can.
>
> OK.
>
> > In this failing state, mergetool may be confused by a left-over
> > state from previous rerere activity.
>
> It is unclear to me what relevance this has to this patch.  Does it
> have this sequence:
>
> "previous rerere activity" (whatever that is)
> test_must_fail git stash apply &&
> git mergetool
>
> and demonstrate that "git mergetool" fails because there is a wrong
> rerere state in the repository after "git stash apply" returns?
>
> Or perhaps you are relying on the state that is left by the previous
> test piece?

The previous edition of this patch explicitly created the condition
which would confuse mergetool by creating a conflict and resolving it.
 The mergetool confusion is what I was testing and is what lead to
this patch series.

But I have since learned that rerere _can_ be effective after a stash
conflict, but it was not invoked automatically. This series aims to
fix that instead of simply forcing rerere to clean up in the stash
conflict case.

I left the concern in the commit message because this is more than a
missing feature; under certain conditions, it is a bug.  But I could
have reworded it to be more clear.

I am not relying on a prior condition to exist.  In fact the 'git
reset' at the start of this test will clear the previous rerere state
that I am testing for in this test.

In the previous edition, the test was this:
  Verify mergetool is (not) confused by unclean rerere behavior:
1. Set up a normal merge-conflict with rerere so that MERGE_RR exists
2. Set up a conflicted stash-pop
3. Confirm/test the aberrant behavior of mergetool

In this edition, the aim of the test is different:
  Verify rerere is (not) called by a conflict stash-apply:
1. Set up a conflicted stash-pop
2. Confirm/test whether rerere tracks the result

> > Also, the next test expected us to finish up with a reset, which
> > is impossible to do if we fail (as we must) and it's an
> > unreasonable expectation anyway.  Begin the next test with a reset
> > of his own instead.
>
> Yes, it is always a good discipline to start a new test piece from a
> known state.
>
> > @@ -193,7 +203,37 @@ test_expect_success 'mergetool skips resolved paths 
> > when rerere is active' '
> >  git reset --hard
> >  '
> >
> > +test_expect_failure 'conflicted stash sets up rerere'  '
> > +git config rerere.enabled true &&
> > +git checkout stash1 &&
> > +echo "Conflicting stash content" >file11 &&
> > +git stash &&
> > +
> > +git checkout --detach stash2 &&
> > +test_must_fail git stash apply &&
> > +
> > +test -e .git/MERGE_RR &&
> > +test -n "$(git ls-files -u)" &&
> > +conflicts="$(git rerere remaining)" &&
>
> Checking that the index is conflicted with "ls-files -u" and asking
> the public API "git rerere remaining" to see what paths rerere
> thinks it did not touch, like you do in the second and third lines,
> are very sensible, but it is probably not a good idea for this test
> to check implementation details with "test -f .git/MERGE_RR".

I tend to agree.  However, it is the presence of .git/MERGE_RR which
will cause mergetool to take the 'rerere remaining' path.  I wanted to
ensure that mergetool is going to go the way I expected.  In light of
the later actions in this test, that is probably overkill.  I can
remove it.

> > +test "$conflicts" = "file11" &&
> > +output="$(git mergetool --no-prompt)" &&
> > +test "$output" != "No files need merging" &&
> > +
> > +git commit -am "save the stash resolution" &&
> > +
> > +git reset --hard stash2 &&
> > +test_must_fail git stash apply &&
> > +
> > +test -e .git/MERGE_RR &&
> > +test -n "$(git ls-files -u)" &&
> > +conflicts="$(git rerere remaining)" &&
>
> Likewise.

And ditto.


> > +test -z "$conflicts" &&
> > +output="$(git mergetool --no-prompt)" &&
> > +test "$output" = "No files need merging"
> > +'
> > +
> >  test_expect_success 'mergetool takes partial path' '
> > +git reset --hard
> >  git config rerere.enabled false &&
> >  git checkout -b test12 branch1 &&
> >  git submodule update -N &&

So, the next roll will remove the tests for MERGE_RR and will be more
explicit about the potential for mergetool confusion and/or the fact
that it is not explicitly tested here.

I'll wait a little longer for any further comments.

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] Change configure to check if pthreads are usable without any extra flags

[Junio C Hamano]

Max Horn  writes:

> The configure script checks whether certain flags / libraries are
> required to use pthreads. But so far it did not consider the possibility
> that no extra compiler flags are needed (as is the case on Mac OS X). As
> a result, configure would always add "-mt" to the list of flags. This in
> turn triggered a warning in clang about an unknown argument.
> To solve this, we now first check if pthreads work without extra flags.
>
> Signed-off-by: Max Horn 
> ---
>  configure.ac | 2 +-
>  1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
>
> diff --git a/configure.ac b/configure.ac
> index 4e9012f..d767ef3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1002,7 +1002,7 @@ if test -n "$USER_NOPTHREAD"; then
>  # -D_REENTRANT' or some such.
>  elif test -z "$PTHREAD_CFLAGS"; then
>threads_found=no
> -  for opt in -mt -pthread -lpthread; do
> +  for opt in "" -mt -pthread -lpthread; do

Hmph.  Would it work to append the new empty string at the end of
the existing list, as opposed to prepending it?  I'd prefer a
solution that is order independent, or if the change is order
dependent, then a comment to warn others from changing it later.

>   old_CFLAGS="$CFLAGS"
>   CFLAGS="$opt $CFLAGS"
>   AC_MSG_CHECKING([Checking for POSIX Threads with '$opt'])

Perhaps "for linking with POSIX Threads" would make it clearer, as
CFLAGS (rather, PTHREAD_CFLAGS) has been checked earlier separately.

--
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 02.5/11] Makefile: fold XDIFF_H and VCSSVN_H into LIB_H

[Junio C Hamano]

Jonathan Nieder  writes:

> Just like MISC_H (see previous commit), there is no reason to track
> xdiff and vcs-svn headers separately from the rest of the headers.
> The only purpose of these variables is to keep track of recompilation
> dependencies.
>
> As a pleasant side effect, folding these into LIB_H lets us stop
> tracking GIT_OBJS and VCSSVN_TEST_OBJS separately from the list of all
> OBJECTS.
>
> Signed-off-by: Jonathan Nieder 
> ---
> Jeff King wrote:
>> On Wed, Jun 20, 2012 at 04:07:30PM -0500, Jonathan Nieder wrote:
>
>>> Should XDIFF_H and VCSSVN_H be folded into STATIC_HEADERS, too?
>>
>> I stopped short of that, but I'd be tempted to do so.
>
> Here goes.

Very tempting.  Will try squeezing this in between 2/11 and 3/11 and
see how the result looks.
--
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] Document rev^! and rev^@ as revision specifiers

[Max Horn]

> 
On 06.07.2012, at 21:18, Junio C Hamano wrote:

> Max Horn  writes:
> 
 +'{caret}!', e.g. 'HEAD{caret}!'::
 +  A suffix '{caret}' followed by an exclamation mark
 +  means commit '' but forces all of its parents to be excluded. For
 +  commands that deal with a single revision, this is the same as '".
>>> 
>>> Is this sentence correct?  "git commit -C 'HEAD^!'" might be a
>>> command that expects a single revision, but I do not think it is the
>>> same as "git commit -C HEAD".
>> 
>> Ignoring the exact words I used for the moment, what I meant is that these 
>> two commands should be functionally equivalent. Aren't they?
> 
> No.  When a single commit is wanted HEAD^! shouldn't be used, and
> they cannot be functionally equivalent.  I haven't tried but I think
> "commit -C HEAD^!"  would give you a syntax error.
> 

Indeed, it says
 fatal: could not lookup commit HEAD^!

I'll iterate over this once more.

Cheers,
Max--
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 and Quilt

[Jiang Xin]

2012/7/9 Jimmy Thrasibule :
> I have a core project on which I maintain a set of patches using Quilt.

Git + Topgit is a better solution for your case. See:

 * http://repo.or.cz/w/topgit.git/blob/HEAD:/README

E.g. In my fork of topgit, quilt patches resident in "debian/patches" directory:

 * https://github.com/ossxp-com/topgit/tree/master/debian/patches/t

And these patches are exported from the topic branches using this command:

 * https://github.com/ossxp-com/topgit/blob/master/debian/rules#L53

Git also has a command which can import quilt patches as commits
on to the current branch:

$ git quiltimport

-- 
Jiang Xin
--
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] Change configure to check if pthreads are usable without any extra flags

[Max Horn]

On 09.07.2012, at 16:50, Junio C Hamano wrote:

> Max Horn  writes:
> 
>> The configure script checks whether certain flags / libraries are
>> required to use pthreads. But so far it did not consider the possibility
>> that no extra compiler flags are needed (as is the case on Mac OS X). As
>> a result, configure would always add "-mt" to the list of flags. This in
>> turn triggered a warning in clang about an unknown argument.
>> To solve this, we now first check if pthreads work without extra flags.
>> 
>> Signed-off-by: Max Horn 
>> ---
>> configure.ac | 2 +-
>> 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
>> 
>> diff --git a/configure.ac b/configure.ac
>> index 4e9012f..d767ef3 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1002,7 +1002,7 @@ if test -n "$USER_NOPTHREAD"; then
>> # -D_REENTRANT' or some such.
>> elif test -z "$PTHREAD_CFLAGS"; then
>>   threads_found=no
>> -  for opt in -mt -pthread -lpthread; do
>> +  for opt in "" -mt -pthread -lpthread; do
> 
> Hmph.  Would it work to append the new empty string at the end of
> the existing list, as opposed to prepending it?

No, because that loop aborts on the first match that "works". Since no flags 
are necessary on OS X, but adding "-mt" to the flags "works" in the sense that 
it does nothing (except triggering a warning about an unknown argument), we 
need to check the empty string before "-mt" that. 

>  I'd prefer a
> solution that is order independent, or if the change is order
> dependent, then a comment to warn others from changing it later.

Well, such checks are normally always order dependant, too (looking at many 
other autoconf tests out there). OK, so we could first test all four 
possibilities, recording for each whether it works or not. But after doing 
that, we still need to establish an order, in case more than one "works" 
according to the linker test. Simply using the order is the easiest way for 
that and works well in practice. And it avoid unnecessary, time consuming 
checks ;).

Regardless of all that, of course I can add a comment emphasising that the 
order here is important. (Although IMHO that should be self-evident for an 
autoconf test.)



> 
>>  old_CFLAGS="$CFLAGS"
>>  CFLAGS="$opt $CFLAGS"
>>  AC_MSG_CHECKING([Checking for POSIX Threads with '$opt'])
> 
> Perhaps "for linking with POSIX Threads" would make it clearer, as
> CFLAGS (rather, PTHREAD_CFLAGS) has been checked earlier separately.

Well, talking about clarity, looking at line 188 it says
   AC_MSG_NOTICE([Will try -pthread then -lpthread to enable POSIX Threads])

which is also bad: It is out-of-date (even before my patch, as it doesn't 
mention -mt), will easily get out of sync with reality again, and in any case 
contains information that normally shouldn't be printed anyway. 

Beyond that, the pthread code checks only for -pthread and -lpthread, thus 
leaving many systems out. Indeed, it might be worth a thought dropping the 
custom pthread detection code in git's configure.ac and instead using 
AX_PTHREAD , 
which covers many more systems out of the box. 

But for now, I really would just want to make this simple trivial fix that 
avoids tons of pointless warnings when compiling git on Mac OS X 10.7 ... ;).


Cheers,
Max


--
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: Student project in Ensimag: thanks all!

[Junio C Hamano]

Matthieu Moy  writes:

> For the third year, I offered my students to contribute to open-source
> software as part of a school project. This year, we had one team on the
> core of Git (who implemented better advices for "git status", the XDG
> configuration directory, and "git rebase -i --exec"), and two working on
> the Git-mediawiki interface (one worked on new features like support for
> mediafiles and authentication using the git credentials mechanism, and
> another on an automated testsuite).
>
> The project itself ended a while ago, but some of the patch series
> needed extra care to end up in pu. This is now done :-).

Thanks for introducing your students to the development community.
I enjoyed interactions with new contributors, wish them luck, and
hope (at least some of) them who are interested to remain here.

> A few series have been abandoned ("bisect old/new", and "warn before
> rebase/commit"), I've added pointers to the gmane threads on the page
> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
> in case someone wants to continue the work.

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: Using git commit --amend on a commit with an empty message

[Junio C Hamano]

Chris Webb  writes:

> In fact, we even fail to start the editor if --allow-empty-message is
> explicitly provided:
>
>   $ git commit --allow-empty --allow-empty-message -m ''
>   $ git commit --amend --allow-empty-message
>   fatal: commit has empty message
>
> Assuming this isn't intentional for some reason I don't understand, I think
> this is the correct tiny fix? make test succeeds fine both before and after.

Yeah, it is a "bug" that exists only because nobody sane uses empty
message commits, let alone tries to amend such commits, hence went
unnoticed for a long time.

The patch looks sane; if we want to keep this as a feature or a
bugfix, we may want to pretect it with a new test, though.

Thanks.

> -- >8 --
> Subject: [PATCH] Allow edit of empty message with commit --amend
>
> If git commit --amend is used on a commit with an empty message, it fails
> unless -m is given, whether or not --allow-empty-message is specified.
>
> Instead, allow it to proceed to the editor with an empty commit message.
> Unless --allow-empty-message is in force, it will still abort later if an
> empty message is saved from the editor. (That check was already present
> and necessary to prevent a non-empty commit message being edited to an
> empty one.)
>
> Signed-off-by: Chris Webb 
> ---
>  builtin/commit.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index f43eaaf..6515da2 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -640,7 +640,7 @@ static int prepare_to_commit(const char *index_file, 
> const char *prefix,
>   hook_arg1 = "message";
>   } else if (use_message) {
>   buffer = strstr(use_message_buffer, "\n\n");
> - if (!buffer || buffer[2] == '\0')
> + if (!use_editor && (!buffer || buffer[2] == '\0'))
>   die(_("commit has empty message"));
>   strbuf_add(&sb, buffer + 2, strlen(buffer + 2));
>   hook_arg1 = "commit";
--
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] Change configure to check if pthreads are usable without any extra flags

[Junio C Hamano]

Max Horn  writes:

>>> diff --git a/configure.ac b/configure.ac
>>> index 4e9012f..d767ef3 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -1002,7 +1002,7 @@ if test -n "$USER_NOPTHREAD"; then
>>> # -D_REENTRANT' or some such.
>>> elif test -z "$PTHREAD_CFLAGS"; then
>>>   threads_found=no
>>> -  for opt in -mt -pthread -lpthread; do
>>> +  for opt in "" -mt -pthread -lpthread; do
>> 
>> Hmph.  Would it work to append the new empty string at the end of
>> the existing list, as opposed to prepending it?
>
> No, because that loop aborts on the first match that "works". Since no flags 
> are necessary on OS X, but adding "-mt" to the flags "works" in the sense 
> that it does nothing (except triggering a warning about an unknown argument), 
> we need to check the empty string before "-mt" that. 

If the test in that "for opt ...; do" considers the linking "work",
why do you even want to tweak it, and instead let "-mt" be passed?

If the warning troubles you, would it be feasible for the purpose of
the check to tweak the definition of "works" used in the loop so that
it considers the warning as "not working"?
--
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: Using git commit --amend on a commit with an empty message

[Chris Webb]

Junio C Hamano  writes:

> Yeah, it is a "bug" that exists only because nobody sane uses empty
> message commits, let alone tries to amend such commits, hence went
> unnoticed for a long time.

Quite. I only noticed it because this is the default behaviour of Github
gists and I wanted to replace the empty commit messages with more meaningful
ones.

> The patch looks sane; if we want to keep this as a feature or a
> bugfix, we may want to pretect it with a new test, though.

Yes, it's hardly something people will test often. Okay, I'll send a version
two with a suitable test.

Best wishes,

Chris.
--
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] Restore umasks influence on the permissions of work tree created by clone

[Alex Riesen]

On Mon, Jul 9, 2012 at 3:41 AM, Junio C Hamano  wrote:
> Alex Riesen  writes:
>
>> The original (shell coded) version of the git-clone just used mkdir(1)
>> to create the working directories. The builtin changed the mode argument
>> to mkdir(2) to 0755, which was a bit unfortunate, as there are use
>
> A much more important reason why this is a good change (I think you
> could even say this is a bugfix) is because directories and files in
> the working tree are created with entry.c::create_directories() and
> entry.c::create_file(), and they do honour umask settings, and the
> top-level of the working tree should be handled the same way, no?

Well, the top-level directories of anything are often handled specially,
but yes, I agree indeed. Frankly, I wondered why the top-level wasn't
created safe_create_leading_directories() or something like that.

>> cases where umask-controlled creation is preferred and in any case
>> it is a well-known behaviour for new directory/file creation.
>
> Sign-off?

It was an RFC until now :)

Signed-off-by: Alex Riesen 
--
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] Change configure to check if pthreads are usable without any extra flags

[Max Horn]

On 09.07.2012, at 19:44, Junio C Hamano wrote:

> Max Horn  writes:
> 
 diff --git a/configure.ac b/configure.ac
 index 4e9012f..d767ef3 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1002,7 +1002,7 @@ if test -n "$USER_NOPTHREAD"; then
 # -D_REENTRANT' or some such.
 elif test -z "$PTHREAD_CFLAGS"; then
  threads_found=no
 -  for opt in -mt -pthread -lpthread; do
 +  for opt in "" -mt -pthread -lpthread; do
>>> 
>>> Hmph.  Would it work to append the new empty string at the end of
>>> the existing list, as opposed to prepending it?
>> 
>> No, because that loop aborts on the first match that "works". Since no flags 
>> are necessary on OS X, but adding "-mt" to the flags "works" in the sense 
>> that it does nothing (except triggering a warning about an unknown 
>> argument), we need to check the empty string before "-mt" that. 
> 
> If the test in that "for opt ...; do" considers the linking "work",
> why do you even want to tweak it, and instead let "-mt" be passed?
> 
> If the warning troubles you,

It does trouble me, as it means that every single compiled file now triggers a 
warning, making it impossible to use -Werror, or alternatively much harder to 
spot legit warning. In fact, I am surprised that it doesn't seem to trouble 
*you* :-).

Moreover, while compiling and link "works" with "-mt" present on my system, it 
is very easy to imagine a setup where this test does break: namely on a system 
where pthreads are in the C lib, but the C compiler treats unknown compiler 
options as an error, not a warning. Then none of the three options the test 
checks right now would work

As I see it, an autoconf feature test like this should be checking "which 
linker flags are *required* in order to use pthreads?". But what it currently 
does is to check "which linker flags do not prevent us from (and possibly help 
us to) use pthreads?"  and so they come up with flags that are not necessary, 
and in fact trigger warnings.


> would it be feasible for the purpose of
> the check to tweak the definition of "works" used in the loop so that
> it considers the warning as "not working"?

That would be possible, and probably a good idea. But it is also completely 
orthogonal to my patch. Indeed, if done without my patch, then as a result, 
pthreads would not be detected anymore on Mac OS X, since none of the linker 
flags it tries would work -- as it doesn't try what happens when no linker 
flags are passed.



Cheers,
Max--
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 1/2] rm: don't fail when removing populated submodules

[Jens Lehmann]

Am 09.07.2012 04:17, schrieb Junio C Hamano:
> Jens Lehmann  writes:
> So I still think "--recurse-submodules" does not make any sense to
> the "rm" command.  I would understand a "Do not attempt to remove
> submodules and ignore their existence altogether" option, even
> though I do not think it is useful.

Yes, when "rm" removes populated submodule work trees by default
then there is no need for a "--recurse-submodules" option. And
then we don't need a "--no-recurse-submodules" either as that use
case is already covered by the "--cached" option, right?

>> All other core commands happily change the index without updating
>> the submodule's work tree.
> 
> What are "all other core commands"?  "fetch" by definition does not
> touch working tree inside or outside working tree.  "add" is about
> recording the state from the working tree to the index, and
> following the earlier point you raised (I unfortunately culled from
> the quote), as the rest of core Git considers a submodule a single
> path entity in the context of the superproject, "the state from the
> working tree" for the submodule is where its HEAD points at, so it
> is correct not to look at the working tree.

I wanted to say "all other /work tree updating/ core commands"
here (checkout, merge, reset ...). Sorry for the confusion.

> Without going outside the context of "rm", I think the current
> behaviour of "git rm path" for submodule is merely punting---erroring
> out against a request for an unimplemented feature.
> 
> If you ask an unpopulated submodule to be removed, we could simply
> rmdir() it and remove the entry from the index, but that is far
> insufficient for handling a submodule repository that is already
> "init"ed.  And we did not want to plug the "check if removal will
> lose any state from the submodule repository" logic because the
> information is no use for us for a long time until we added the
> "gitfile" support to allow us to relocate path/.git for the
> submodule safely away when we remove the working tree of it.
> 
> But now we do have gitfile, so we could remove submodule working
> tree.  I think not erroring out and removing only the index entry is
> a irresponsible thing to do.  It would mean that we pretend as if a
> feature that was earlier unimplemented (hence errored out) is now
> supported, but it does not do what the user asked us to do, no?
> 
> I do not know what other commands you have in mind, but some of them
> may be similar "recursing down and performing an operation that
> potentially can fail is too complex, and we are not sure if we have
> enough sequencing infrastructure to guide the user to sort out the
> mess in the half-result, so let's punt and not to that part and have
> the user sort out" half-features, and if that is the case, I do not
> think it is prudent to model "rm", which is something that we now
> could implement properly, with the necessary infrastructure already
> in place, after them.

Cool, so let's drop this patch and I'll teach "rm" to handle
populated submodules according to what we do for regular files:
Make sure there are no modifications which could get lost (unless
"-f") and remove all tracked files and the gitfile from the work
tree (unless "--cached") before removing the submodule from the
index. If the submodule uses the old layout with the .git
directory instead of a gitfile we error out just like we do today.

And we didn't talk about untracked or ignored files which may live
inside the submodules work tree so far, but according to what a
"rm -r" does in the superproject they should still be around after
using "rm" on a populated submodule, right?
--
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] Allow edit of empty message with commit --amend

[Chris Webb]

If git commit --amend is used on a commit with an empty message, it fails
unless -m is given, whether or not --allow-empty-message is specified.

Instead, allow it to proceed to the editor with an empty commit message.
Unless --allow-empty-message is in force, it will still abort later if an
empty message is saved from the editor. (This check was already necessary
to prevent a non-empty commit message being edited to an empty one.)

Add a test for --amend --edit of an empty commit message which fails
without this fix, as it's a rare case that won't get frequently tested
otherwise.

Signed-off-by: Chris Webb 
---
 builtin/commit.c  |2 +-
 t/t7501-commit.sh |   15 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index f43eaaf..6515da2 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -640,7 +640,7 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
hook_arg1 = "message";
} else if (use_message) {
buffer = strstr(use_message_buffer, "\n\n");
-   if (!buffer || buffer[2] == '\0')
+   if (!use_editor && (!buffer || buffer[2] == '\0'))
die(_("commit has empty message"));
strbuf_add(&sb, buffer + 2, strlen(buffer + 2));
hook_arg1 = "commit";
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index b20ca0e..5ad636b 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -138,6 +138,21 @@ test_expect_success '--amend --edit' '
test_cmp expect msg
 '
 
+test_expect_success '--amend --edit of empty message' '
+   cat >replace <<-\EOF &&
+   #!/bin/sh
+   echo "amended" >"$1"
+   EOF
+   chmod 755 replace &&
+   echo amended >expect &&
+   git commit --allow-empty --allow-empty-message -m "" &&
+   echo more bongo >file &&
+   git add file &&
+   EDITOR=./replace git commit --edit --amend &&
+   git diff-tree -s --format=%s HEAD >msg &&
+   test_cmp expect msg
+'
+
 test_expect_success '-m --edit' '
echo amended >expect &&
git commit --allow-empty -m buffer &&
-- 
1.7.10

--
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] Change configure to check if pthreads are usable without any extra flags

[Junio C Hamano]

Max Horn  writes:

>> would it be feasible for the purpose of
>> the check to tweak the definition of "works" used in the loop so that
>> it considers the warning as "not working"?
>
> That would be possible, and probably a good idea. But it is also
> completely orthogonal to my patch. Indeed, if done without my
> patch,...

No, I was suggesting it as a possible way to make the addition of ""
order independent (which you said is impossible in your initial
reply).

--
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 1/2] rm: don't fail when removing populated submodules

[Junio C Hamano]

Jens Lehmann  writes:

> Cool, so let's drop this patch and I'll teach "rm" to handle
> populated submodules according to what we do for regular files:
> Make sure there are no modifications which could get lost (unless
> "-f") and remove all tracked files and the gitfile from the work
> tree (unless "--cached") before removing the submodule from the
> index. If the submodule uses the old layout with the .git
> directory instead of a gitfile we error out just like we do today.

Alternatively we could "mv" .git directory out of the way and the
next "git checkout" of a branch that still has the submodule can
make a gitfile to point there, no?

Or we can just error out and tell the user to do so herself.

> And we didn't talk about untracked or ignored files which may live
> inside the submodules work tree so far, but according to what a
> "rm -r" does in the superproject they should still be around after
> using "rm" on a populated submodule, right?

Until we add the "precious" class, untracked and ignored files are
expendable, so if a submodule working tree has no modification and
only has leftover *.o files, they can be nuked as part of submodule
removal, but if it has an untracked and unignored *.c file for
example, the "rm" operation without "-f" should be stopped, no?
--
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 v2] Allow edit of empty message with commit --amend

[Junio C Hamano]

Chris Webb  writes:

> If git commit --amend is used on a commit with an empty message, it fails
> unless -m is given, whether or not --allow-empty-message is specified.
>
> Instead, allow it to proceed to the editor with an empty commit message.
> Unless --allow-empty-message is in force, it will still abort later if an
> empty message is saved from the editor. (This check was already necessary
> to prevent a non-empty commit message being edited to an empty one.)
>
> Add a test for --amend --edit of an empty commit message which fails
> without this fix, as it's a rare case that won't get frequently tested
> otherwise.
>
> Signed-off-by: Chris Webb 

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

[GSoC] Designing a faster index format - Progress report week 12

[Thomas Gummerer]

== Work done in the previous 11 weeks ==

- Definition of a tentative index file v5 format [1]. This differs
  from the proposal in making it possible to bisect the directory
  entries and file entries, to do a binary search. The exact bits
  for each section were also defined. To further compress the index,
  along with prefix compression, the stat data is hashed, since
  it's only used for comparison, but the plain data is never used.
  Thanks to Michael Haggerty, Nguyen Thai Ngoc Duy, Thomas Rast
  and Robin Rosenberg for feedback.
- Prototype of a converter from the index format v2/v3 to the index
  format v5. [2] The converter reads the index from a git repository,
  can output parts of the index (header, index entries as in
  git ls-files --debug, cache tree as in test-dump-cache-tree, or
  the reuc data). Then it writes the v5 index file format to
  .git/index-v5. Thanks to Michael Haggerty for the code review.
- Prototype of a reader for the new index file format. [3] The
  reader has mainly the purpose to show the algorithm used to read
  the index lexicographically sorted after the full name which is
  required by the current internal memory format. Big thanks for
  reviewing this code and giving me advice on refactoring goes
  to Michael Haggerty.
- Read the index format format and translate it to the current in
  memory format. This doesn't include reading any of the current
  extensions, which are now part of the main index. The code again
  is on github. [4] Thanks for reviewing the first steps to Thomas
  Rast.
- Read the cache-tree data (formerly an extension, now it's integrated
  with the rest of the directory data) from the new ondisk format.
  There are still a few optimizations to do in this algorithm.
- Started implementing the API (suggested by Duy), but it's still
  in the very early stages. There is one commit for this on GitHub [1],
  but it's a very early work in progress.
- Started implementing the writer, which extracts the directories from
  the in-memory format, and writes the header and the directories to
  disk.
- I found a few bugs in the algorithm for extracting the directories
  and decided to completely rewrite it, using a hash table instead of
  simple lists, since the old one would have to many corner cases to
  handle.
- Implemented writing the file block to disk, and basic tests from the
  test suite are running fine, not including tests that require
  conflicted data or the cache-tree to work, which both are not
  implemented yet.

== Work done in the last week ==

- Unfortunately this weeks progress was slower than expected due to
  exams at university. Those are now over however, so I can fully
  concentrate on the work for Google Summer of Code.
- This week I started implementing a patch to replace the ce_namelen()
  function with a field ce_namelen field in struct cache_entry. This
  will both give us some extra bits of performance in some (rare)
  cases with the old index format, and is a refactoring for index-v5,
  which won't store the length in the flags. The thread for the patch
  is here [5]. Thanks to Junio, Duy and Thomas for reviews of this patch.

== Outlook for the next week ==

- Polish the patch for the ce_namelen field.
- Implement the cache-tree and conflict data writing to the index file.

[1] https://github.com/tgummerer/git/wiki/Index-file-format-v5
[2] https://github.com/tgummerer/git/blob/pythonprototype/git-convert-index.py
[3] https://github.com/tgummerer/git/blob/pythonprototype/git-read-index-v5.py
[4] https://github.com/tgummerer/git/tree/index-v5
[5] http://thread.gmane.org/gmane.comp.version-control.git/200997
--
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 2012, #02; Mon, 9)

[Junio C Hamano]

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

The fourth and fifth batches of topics have graduated to 'master'.

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

--
[New Topics]

* jl/submodule-rm (2012-07-05) 2 commits
 - rm: remove submodules from the index and the .gitmodules file
 - rm: don't fail when removing populated submodules

* mh/maint-revisions-doc (2012-07-05) 2 commits
 - Document rev^! and rev^@ as revision specifiers
 - Make  documentation more consistent.

The tip one is a bit suspicious.

* nk/maint-gitweb-log-by-lines (2012-07-05) 3 commits
 - gitweb: Add support to Link: tag
 - gitweb: Handle other types of tag in git_print_log
 - gitweb: Cleanup git_print_log()

Is the use of esc_html() in the tip one correct?

* pw/git-p4-jobs (2012-07-05) 3 commits
 - git p4: notice Jobs lines in git commit messages
 - git p4 test: refactor marshal_dump
 - git p4: remove unused P4Submit interactive setting

Will merge to 'next'.

* pw/git-p4-move (2012-07-05) 2 commits
 - git p4: add support for 'p4 move' in P4Submit
 - git p4: refactor diffOpts calculation

Will be rerolled.

* ar/clone-honor-umask-at-top (2012-07-08) 1 commit
 - Restore umasks influence on the permissions of work tree created by clone

May want to rephrase the log message a bit.

Will merge to 'next'.

* jn/vcs-svn (2012-07-05) 12 commits
  (merged to 'next' on 2012-07-09 at 1d97a8f)
 + vcs-svn: allow 64-bit Prop-Content-Length
 + vcs-svn: suppress a signed/unsigned comparison warning
 + vcs-svn: suppress a signed/unsigned comparison warning
 + vcs-svn: suppress signed/unsigned comparison warnings
 + vcs-svn: use strstr instead of memmem
 + vcs-svn: use constcmp instead of prefixcmp
 + vcs-svn: simplify cleanup in apply_one_window
 + vcs-svn: avoid self-assignment in dummy initialization of pre_off
 + vcs-svn: drop no-op reset methods
 + vcs-svn: suppress -Wtype-limits warning
 + vcs-svn: allow import of > 4GiB files
 + vcs-svn: rename check_overflow and its arguments for clarity

Reroll of db/vcs-svn.

Will merge to 'master'.

* mm/mediawiki-tests (2012-07-06) 12 commits
  (merged to 'next' on 2012-07-09 at 4d874e8)
 + git-remote-mediawiki: be more defensive when requests fail
 + git-remote-mediawiki: more efficient 'pull' in the best case
 + git-remote-mediawiki: extract revision-importing loop to a function
 + git-remote-mediawiki: refactor loop over revision ids
 + git-remote-mediawiki: change return type of get_mw_pages
 + git-remote-mediawiki (t9363): test 'File:' import and export
 + git-remote-mediawiki: support for uploading file in test environment
 + git-remote-mediawiki (t9362): test git-remote-mediawiki with UTF8 characters
 + git-remote-mediawiki (t9361): test git-remote-mediawiki pull and push
 + git-remote-mediawiki (t9360): test git-remote-mediawiki clone
 + git-remote-mediawiki: test environment of git-remote-mediawiki
 + git-remote-mediawiki: scripts to install, delete and clear a MediaWiki
 (this branch uses mm/mediawiki-file-attachments.)

Will merge to 'master'.

* ph/stash-rerere (2012-07-08) 2 commits
 - stash: invoke rerere in case of conflict
 - test: git-stash conflict sets up rerere

Will be rerolled but is going in the right direction.

* tg/ce-namelen (2012-07-08) 1 commit
 - Replace strlen() with ce_namelen()

Trivially correct clean-up and micro optimization.

* jn/makefile-cleanup (2012-07-09) 14 commits
 - Makefile: document ground rules for target-specific dependencies
 - Makefile: move GIT-VERSION-FILE dependencies closer to use
 - Makefile: build instaweb similar to other scripts
 - Makefile: update scripts when build-time parameters change
 - Makefile: do not replace @@GIT_VERSION@@ in shell scripts
 - Makefile: split prefix flags from GIT-CFLAGS
 - Makefile: be silent when only GIT_USER_AGENT changes
 - Makefile: split GIT_USER_AGENT from GIT-CFLAGS
 - Makefile: do not replace @@GIT_USER_AGENT@@ in scripts
 - Makefile: apply dependencies consistently to sparse/asm targets
 - Makefile: do not have git.o depend on common-cmds.h
 - Makefile: fold XDIFF_H and VCSSVN_H into LIB_H
 - Makefile: fold MISC_H into LIB_H
 - Makefile: sort LIB_H list
 (this branch is tangled with jk/version-string-dependency.)

Tweaks and replaces jk/version-string-dependency.

Will merge to 'next'.

* cw/amend-commit-without-message (2012-07-09) 1 commit
 - Allow edit of empty message with commit --amend

"commit --amend" used to refuse amending a commit with an empty log
message, with or without "--allow-empty-message".

Will merge to 'next'.

--
[Graduated to "master"]

* cw/help-over-network (2012-06-28) 2 commits
  (merged to 'next' on 2012-07-03 at 99e8d28)
 + Allow help.htmlpath to be a URL prefix

Re: [RFC PATCH 1/2] rm: don't fail when removing populated submodules

[Jens Lehmann]

Am 09.07.2012 21:38, schrieb Junio C Hamano:
> Jens Lehmann  writes:
> 
>> Cool, so let's drop this patch and I'll teach "rm" to handle
>> populated submodules according to what we do for regular files:
>> Make sure there are no modifications which could get lost (unless
>> "-f") and remove all tracked files and the gitfile from the work
>> tree (unless "--cached") before removing the submodule from the
>> index. If the submodule uses the old layout with the .git
>> directory instead of a gitfile we error out just like we do today.
> 
> Alternatively we could "mv" .git directory out of the way and the
> next "git checkout" of a branch that still has the submodule can
> make a gitfile to point there, no?

Yup. That would mean a smooth transition for legacy .git-dir
submodules into the new gitfile world.

>> And we didn't talk about untracked or ignored files which may live
>> inside the submodules work tree so far, but according to what a
>> "rm -r" does in the superproject they should still be around after
>> using "rm" on a populated submodule, right?
> 
> Until we add the "precious" class, untracked and ignored files are
> expendable, so if a submodule working tree has no modification and
> only has leftover *.o files, they can be nuked as part of submodule
> removal, but if it has an untracked and unignored *.c file for
> example, the "rm" operation without "-f" should be stopped, no?

Ok, untracked files mark the submodule modified while ignored files
which are not tracked won't.

Thanks for this discussion, I'll start hacking on that.
--
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] Change configure to check if pthreads are usable without any extra flags

[Max Horn]

On 09.07.2012, at 21:23, Junio C Hamano wrote:

> Max Horn  writes:
> 
>>> would it be feasible for the purpose of
>>> the check to tweak the definition of "works" used in the loop so that
>>> it considers the warning as "not working"?
>> 
>> That would be possible, and probably a good idea. But it is also
>> completely orthogonal to my patch. Indeed, if done without my
>> patch,...
> 
> No, I was suggesting it as a possible way to make the addition of ""
> order independent (which you said is impossible in your initial
> reply).

This would make things "order independent" for the specific subset of pthread 
implementations git supports right now. But there are systems where e.g. both 
-lpthreads and -lpthread work (link correctly, produce no warnings), but only 
one provides a POSIX compliant pthread implementation. For such systems, order 
will play a role, no matter what. Granted, git does not yet support such 
systems (with regards to pthreads, at least) at all. 

But all in all, I don't understand why this order independence seems to be so 
important? To me it seems merely an illusion anyway, not worth the extra effort.


--
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] git-svn: don't create master if another head exists

[Marcin Owsiany]

On Tue, Jun 26, 2012 at 11:32:15PM +0100, Marcin Owsiany wrote:
> On Tue, Jun 26, 2012 at 03:03:07PM -0700, Junio C Hamano wrote:
> > Marcin Owsiany  writes:
> > 
> > > diff --git a/git-svn.perl b/git-svn.perl
> > > index 0b074c4..2379a71 100755
> > > --- a/git-svn.perl
> > > +++ b/git-svn.perl
> > > @@ -1612,9 +1612,9 @@ sub post_fetch_checkout {
> > >   }
> > >   }
> > >  
> > > - my $valid_head = verify_ref('HEAD^0');
> > > + return if verify_ref('HEAD^0');
> > >   command_noisy(qw(update-ref refs/heads/master), $gs->refname);
> > 
> > Given that your original motivation was "I do not want master, I am
> > using something else for my primary branch", I change that still
> > shows "update-ref refs/heads/master" smells like sweeping something
> > under the rug
> 
> I'm not so sure... With this change, git-svn will only create master on
> the initial "clone" and I think that's fine. It's consistent with what
> "git clone" does when cloning a regular git repository.
> 
> It seems that I have slightly misinterpreted git-svn's actions in my
> initial post in 2009. I thought it always updated "master" to the
> most recent upstream commit. In reality it only every _creates_ it at
> the most recent commit. But never fast-forwards it if it pre-exists.
> 
> This makes my idea to do the same to "my something else instead of
> master" much less attractive. In fact I don't think such behaviour would
> be useful.
> 
> I think with the suggested patch git-svn works as I would like it to:
>  - creates "master" at initial checkout - consistent with git clone
>  - using a different "tracking-like" branch is possible with "dcommit"
>  - does not re-create "master" on fetch - so the annoying part is gone

Any comments?

-- 
Marcin Owsiany   http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

"Every program in development at MIT expands until it can read mail."
  -- Unknown
--
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] Change configure to check if pthreads are usable without any extra flags

[Junio C Hamano]

Max Horn  writes:

> But all in all, I don't understand why this order independence
> seems to be so important?

Not so important as long as it is made clear for later people to
patch that part of the code.  I just wanted to make sure that
somebody thought hard enough to judge that it is not worth the
effort to make it independent of the orders with a justification
better than that simply we are too lazy to do so ;-).



--
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] git-svn: don't create master if another head exists

[Junio C Hamano]

Marcin Owsiany  writes:

>> This makes my idea to do the same to "my something else instead of
>> master" much less attractive. In fact I don't think such behaviour would
>> be useful.
>> 
>> I think with the suggested patch git-svn works as I would like it to:
>>  - creates "master" at initial checkout - consistent with git clone
>>  - using a different "tracking-like" branch is possible with "dcommit"
>>  - does not re-create "master" on fetch - so the annoying part is gone
>
> Any comments?

Not from me.  Even though I'd love to hear Eric's opinion, your "I
don't think such behaviour would be useful." gave me an impression
that you would justify the change in a different way (i.e. a rewrite
of proposed log message) or tweak the patch (i.e. a modified
behaviour), or perhaps both, in your re-roll, the ball was in your
court, and we were waiting for such a rerolled patch.
--
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] Restore umasks influence on the permissions of work tree created by clone

[Jeff King]

On Sun, Jul 08, 2012 at 06:41:39PM -0700, Junio C Hamano wrote:

> Alex Riesen  writes:
> 
> > The original (shell coded) version of the git-clone just used mkdir(1)
> > to create the working directories. The builtin changed the mode argument
> > to mkdir(2) to 0755, which was a bit unfortunate, as there are use
> 
> A much more important reason why this is a good change (I think you
> could even say this is a bugfix) is because directories and files in
> the working tree are created with entry.c::create_directories() and
> entry.c::create_file(), and they do honour umask settings, and the
> top-level of the working tree should be handled the same way, no?

Does the mkdir of "rr-cache/*" in rerere.c make the same mistake? The
rr-cache root is made with 0777, and the files inside each subdirectory
are created with 0666.  So it is the only thing preventing users of
shared repos from using rerere.

-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: [PATCH] Restore umasks influence on the permissions of work tree created by clone

[Junio C Hamano]

Jeff King  writes:

> Does the mkdir of "rr-cache/*" in rerere.c make the same mistake? The
> rr-cache root is made with 0777, and the files inside each subdirectory
> are created with 0666.  So it is the only thing preventing users of
> shared repos from using rerere.

Quite possibly yes.  I do not recall tightening permissions on
purpose, and it was a long time ago ;-)
--
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] Restore umasks influence on the permissions of work tree created by clone

[Junio C Hamano]

Junio C Hamano  writes:

> Jeff King  writes:
>
>> Does the mkdir of "rr-cache/*" in rerere.c make the same mistake? The
>> rr-cache root is made with 0777, and the files inside each subdirectory
>> are created with 0666.  So it is the only thing preventing users of
>> shared repos from using rerere.
>
> Quite possibly yes.  I do not recall tightening permissions on
> purpose, and it was a long time ago ;-)

Yup, that's the last remaining "mkdir(.*, 755)" in the codebase, and
it should be trivial to replace it with mkdir_in_gitdir() or
something.
--
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] rerere: make rr-cache fanout directory honor umask

[Junio C Hamano]

This is the last remaining call to mkdir(2) that restricts the permission
bits by passing 0755.  Just use the same mkdir_in_gitdir() used to create
the leaf directories.

Signed-off-by: Junio C Hamano 
---
 rerere.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rerere.c b/rerere.c
index dcb525a..651c5de 100644
--- a/rerere.c
+++ b/rerere.c
@@ -524,7 +524,7 @@ static int do_plain_rerere(struct string_list *rr, int fd)
continue;
hex = xstrdup(sha1_to_hex(sha1));
string_list_insert(rr, path)->util = hex;
-   if (mkdir(git_path("rr-cache/%s", hex), 0755))
+   if (mkdir_in_gitdir(git_path("rr-cache/%s", hex)))
continue;
handle_file(path, NULL, rerere_path(hex, "preimage"));
fprintf(stderr, "Recorded preimage for '%s'\n", path);
-- 
1.7.11.1.294.gf7b86df

--
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] filter-branch: do not forget the '@' prefix to force git-timestamp

[Junio C Hamano]

For some reason, this script reinvents, instead of refactoring the
existing one in git-sh-setup, in the ident logic, and it was missed
when git-sh-setup was updated with 2c733fb (parse_date(): '@' prefix
forces git-timestamp, 2012-02-02).

Teach the script that it is OK to have a way ancient timestamp in
the commits that are being filtered.

Signed-off-by: Junio C Hamano 
---
 git-filter-branch.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 804a7f4..b9cded5 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -84,7 +84,7 @@ set_ident () {
s/.*/GIT_'$uid'_EMAIL='\''&'\''; export 
GIT_'$uid'_EMAIL/p
 
g
-   s/^'$lid' [^<]* <[^>]*> \(.*\)$/\1/
+   s/^'$lid' [^<]* <[^>]*> \(.*\)$/@\1/
s/'\''/'\''\'\'\''/g
s/.*/GIT_'$uid'_DATE='\''&'\''; export GIT_'$uid'_DATE/p
 
-- 
1.7.11.1.294.gf7b86df

--
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] rerere: make rr-cache fanout directory honor umask

[Jeff King]

On Mon, Jul 09, 2012 at 04:28:21PM -0700, Junio C Hamano wrote:

> This is the last remaining call to mkdir(2) that restricts the permission
> bits by passing 0755.  Just use the same mkdir_in_gitdir() used to create
> the leaf directories.
> 
> Signed-off-by: Junio C Hamano 

Looks obviously correct to me.

I notice that grepping finds a few 0644 modes, too. Most of them are
false-positives (e.g., we store and transmit 100644 as a shorthand for
"normal non-executable permissions"). This is the only one that looked
legitimate to me:

-- >8 --
Subject: [PATCH] add: create ADD_EDIT.patch with mode 0666

We should be letting the user's umask take care of
restricting permissions. Even though this is a temporary
file and probably nobody would notice, this brings us in
line with other temporary file creations in git (e.g.,
choosing "e"dit from git-add--interactive).

Signed-off-by: Jeff King 
---
 builtin/add.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/add.c b/builtin/add.c
index 41edd63..815ac4b 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -287,7 +287,7 @@ static int edit_patch(int argc, const char **argv, const 
char *prefix)
argc = setup_revisions(argc, argv, &rev, NULL);
rev.diffopt.output_format = DIFF_FORMAT_PATCH;
DIFF_OPT_SET(&rev.diffopt, IGNORE_DIRTY_SUBMODULES);
-   out = open(file, O_CREAT | O_WRONLY, 0644);
+   out = open(file, O_CREAT | O_WRONLY, 0666);
if (out < 0)
die (_("Could not open '%s' for writing."), file);
rev.diffopt.file = xfdopen(out, "w");
-- 
1.7.10.5.16.ga1c6f1c

--
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: Problems pushing???

[pbGit]

Thanks for all your help.  Running through this a few more times and reading
the net I managed it ; )  I tested it cloning from the command line and all
seems good.

For developement I use eclipse with the eGit plugin.  When I try cloning it
putting all the relevant info in it fails.   I am sure this is due to the
ssh keys. I have set-up my keys accordingly.  Tried using the ssh agent but
with no success.  I can see the agent is running and tested that  and all
seems good with that. The error get is 

ssh://paul@localhost:22:
org.eclipse.jgit.transport.CredentialItem$StringType:Password:
ssh://paul@localhost:22:
org.eclipse.jgit.transport.CredentialItem$StringType:Password:

Hope you can help

--
View this message in context: 
http://git.661346.n2.nabble.com/Problems-pushing-tp7562695p7562762.html
Sent from the git mailing list archive at Nabble.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