Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

[Piotr Krukowiecki]

Jeff King p...@peff.net napisał:
On Thu, Sep 19, 2013 at 11:47:51AM +0200, Piotr Krukowiecki wrote:

   it still ends up as a single function call). The downside is
that it has
   to be remembered at each site that uses strcasecmp, but we do
not use
   pointers to standard library functions very often.
 
  Is it possible to add a test which fails if wrapper is not used?
 
  No test needed for this, as compilation or linkage will fail, I
think.
 
 But only when someone compiles on MinGW, no?

Yeah. I think a more clear way to phrase the question would be: is
there
some trick we can use to booby-trap strcasecmp as a function pointer so
that it fails to compile even on systems where it would otherwise work?

I can't think off-hand of a way to do so using preprocessor tricks, and
even if we could, I suspect the result would end up quite ugly. 

What I meant was: can we add a test (in t/) which greps git source code and 
fails if it finds strcasecmp string? 

It could count number of strcasecmp and expect to find only 1 or exclude  known 
location of the wrapper. 


-- 
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: Has there been any discussion about resumable clones recently ?

[Sitaram Chamarty]

On 09/20/2013 04:48 AM, shirish शिरीष wrote:
 Hi all,
 First of all a big thank you to all for making git. With it being fast
 and cheap (in relation to bandwidth and sizes for subsequent checkouts
 as well as CPU usage) . Please CC me if somebody does answer this mail
 as I'm not subscribed to the list.
 
 The thing I have been failures number of times while trying to clone a
 large repo. The only solution it seems is to ask somebody to make a
 git-bundle and get that bundle via wget or rsync and then unbundle it

Just want to mention that if the server is running gitolite, the admin
can set things up so that this is easy and painless, either for all
repos or just some specific ones.

Such repos can then be cloned like this:

rsync -P git@host:repo.bundle .
# downloads a file called basename of repo.bundle; repeat as
# needed till the whole thing is downloaded
git clone repo.bundle repo
cd repo
git remote set-url origin git@host:repo
git fetch origin# and maybe git pull, etc. to freshen the clone

(yes, I know this is not really a substitute for resumable clone; call
it a stop-gap until that happens!)
--
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: Re-Transmission of blobs?

[Josef Wolf]

On Mon, Sep 16, 2013 at 05:55:36PM -0400, Jeff King wrote:
 On Fri, Sep 13, 2013 at 12:09:35PM +0200, Josef Wolf wrote:
 
I'm not sure I understand correctly. I see that bitmaps can be used to
implement set operations. But how comes that walking the graph requires 
a lot
of CPU? Isn't it O(n)?
   
   Yes and no. Your n there is the entirety of history.
  
  Is this really true?
 
 Yes. If you know that the receiver has commit X, and you want to know if
 it has some blob Y, the only way to know for sure is to look at every
 tree of every commit reachable from X, and see whether any of them
 references Y.

Jeff, in my original example, I did a cherry-pick from origin/somebranch.
Even without asking, we can assume with great probability that
origin/somebranch is available at origin. And the file in question happens to
reside in the tree at the very tip of origin/somebranch, not in some of its
ancestors. In this case, there's no need to search the history at all. And
even in this pretty simple case, the algorithm seems to fail for some reason.

 Yes, you do not have to recurse into sub-trees (or commits) you have
 already seen. And we already do that optimization.

Why is the file re-transmitted, then?


With a little change in the protocol, a very simple optimization could be
implemented, avoiding the complicated bitmap strategy you were talking about:

Please consider Junio's description of the dialog:

[ Junio wrote: ]
 Consider this simple history with only a handful of commits (as
 usual, time flows from left to right):

  E
 /   
A---B---C---D

 where D is at the tip of the sending side, E is at the tip of the
 receiving side.  The exchange goes roughly like this:

(receiving side): what do you have?

(sending side): my tip is at D.

(receiving side): D?  I've never heard of it --- please give it
  to me.  I have E.

(sending side): E?  I don't know about it; must be something you
created since you forked from me.  Tell me about
its ancestors.

(receiving side): OK, I have C.

(sending side): Oh, C I know about. You do not have to tell me
anything more.  A packfile to bring you up to
date will follow.

In the last step, instead of sending a packfile, the sending side should send
a list of the SHA's which would be included in this packfile. The receiving
side would then be able to request all the objects it needs to get up-to-date.

I think this change would be considerably simpler than the reachability bitmap
you are talking about. And it would avoid all those time consuming traversals
through the history and the tree. And it would omit _all_ redundant
retransmissions. Even in the case when sender and receiver do not have _any_
common heads at all, _no_ files at all would be retransmitted unnecessarily.

-- 
Josef Wolf
j...@raven.inka.de
--
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] format-patch: print in-body From only when needed

[Jeff King]

Commit a908047 taught format-patch the --from option,
which places the author ident into an in-body from header,
and uses the committer ident in the rfc822 from header.  The
documentation claims that it will omit the in-body header
when it is the same as the rfc822 header, but the code never
implemented that behavior.

This patch completes the feature by comparing the two idents
and doing nothing when they are the same (this is the same
as simply omitting the in-body header, as the two are by
definition indistinguishable in this case). This makes it
reasonable to turn on --from all the time (if it matches
your particular workflow), rather than only using it when
exporting other people's patches.

Signed-off-by: Jeff King p...@peff.net
---
I had meant for this to be the behavior all along (as shown in the
documentation), and I can't imagine why I didn't implement it along with
the original topic. I never noticed because I didn't turn on --from
all the time in my workflow scripts until recently, but instead just
used it manually when sending other people's patches (which I do only
rarely).

 cache.h |  9 +
 ident.c | 29 +
 pretty.c|  2 +-
 t/t4014-format-patch.sh | 10 ++
 4 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/cache.h b/cache.h
index a47b9c0..bfea954 100644
--- a/cache.h
+++ b/cache.h
@@ -953,6 +953,15 @@ struct ident_split {
  */
 extern int split_ident_line(struct ident_split *, const char *, int);
 
+/*
+ * Compare split idents for equality or strict ordering. Note that we
+ * compare only the ident part of the line, ignoring any timestamp.
+ *
+ * Because there are two fields, we must choose one as the primary key; we
+ * currently arbitrarily pick the email.
+ */
+extern int ident_cmp(const struct ident_split *, const struct ident_split *);
+
 struct checkout {
const char *base_dir;
int base_dir_len;
diff --git a/ident.c b/ident.c
index 1c123e6..b29f81f 100644
--- a/ident.c
+++ b/ident.c
@@ -402,3 +402,32 @@ int git_ident_config(const char *var, const char *value, 
void *data)
 
return 0;
 }
+
+static int buf_cmp(const char *a_begin, const char *a_end,
+  const char *b_begin, const char *b_end)
+{
+   int a_len = a_end - a_begin;
+   int b_len = b_end - b_begin;
+   int min = a_len  b_len ? a_len : b_len;
+   int cmp;
+
+   cmp = memcmp(a_begin, b_begin, min);
+   if (cmp)
+   return cmp;
+
+   return a_len - b_len;
+}
+
+int ident_cmp(const struct ident_split *a,
+ const struct ident_split *b)
+{
+   int cmp;
+
+   cmp = buf_cmp(a-mail_begin, a-mail_end,
+ b-mail_begin, b-mail_end);
+   if (cmp)
+   return cmp;
+
+   return buf_cmp(a-name_begin, a-name_end,
+  b-name_begin, b-name_end);
+}
diff --git a/pretty.c b/pretty.c
index 74563c9..b4e32b7 100644
--- a/pretty.c
+++ b/pretty.c
@@ -432,7 +432,7 @@ void pp_user_info(struct pretty_print_context *pp,
map_user(pp-mailmap, mailbuf, maillen, namebuf, namelen);
 
if (pp-fmt == CMIT_FMT_EMAIL) {
-   if (pp-from_ident) {
+   if (pp-from_ident  ident_cmp(pp-from_ident, ident)) {
struct strbuf buf = STRBUF_INIT;
 
strbuf_addstr(buf, From: );
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 668933b..8f272bc 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1000,6 +1000,16 @@ test_expect_success '--from uses committer ident' '
test_cmp expect patch.head
 '
 
+test_expect_success '--from omits redundant in-body header' '
+   git format-patch -1 --stdout --from=A U Thor aut...@example.com 
patch 
+   cat expect -\EOF 
+   From: A U Thor aut...@example.com
+
+   EOF
+   sed -ne /^From:/p; /^$/p; /^---$/q patch patch.head 
+   test_cmp expect patch.head
+'
+
 test_expect_success 'in-body headers trigger content encoding' '
GIT_AUTHOR_NAME=éxötìc test_commit exotic 
test_when_finished git reset --hard HEAD^ 
-- 
1.8.3.4.20.geeaee04.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

[PATCH] t5541: mark passing c-a-s test as success

[Jeff King]

Commit 05c1eb1 (push: teach --force-with-lease to smart-http
transport) fixed the compare-and-swap test in t5541. It
tried to mark the test as passing by teaching the test
helper function to expect an extra success or failure
parameter, but forgot to actually use the parameter in the
helper.

Signed-off-by: Jeff King p...@peff.net
---
On top of jc/push-cas.

 t/lib-httpd.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index dab405d..54dbbfe 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -169,7 +169,7 @@ test_http_push_nonff () {
test_i18ngrep Updates were rejected because output
'
 
-   test_expect_failure 'force with lease aka cas' '
+   test_expect_${EXPECT_CAS_RESULT} 'force with lease aka cas' '
HEAD=$( cd $REMOTE_REPO  git rev-parse --verify HEAD ) 
test_when_finished '\''
(cd $REMOTE_REPO  git update-ref HEAD $HEAD)
-- 
1.8.4.37.g67196dd
--
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: Save notes state when releasing

[Jeff King]

On Fri, Sep 20, 2013 at 07:38:17AM +0200, Francis Moreau wrote:

 I'm using notes in my project. I'm wondering if it's possible to save
 the state of the notes when I'm releasing/tagging a new version of my
 project so I can restore the saved notes state if I checkout back the
 old release.
 
 Therefore I would be able to inspect notes (which may have been
 removed or modified after the release) as they were when the release
 happened.

The notes are stored as git trees, so you can point a tag ref at a
particular state, just as you would with a normal branch. The git tag
command expects to create refs under refs/tags, whereas git notes
expects to find notes under refs/notes. The simplest thing is to just
use git update-ref rather than git tag to create the pointer. Like:

  $ git update-ref refs/notes/v1.0 refs/notes/commits

and then you can always view the v1.0 notes as:

  $ git --notes=v1.0 log

You can even set the notes.displayRef config to always show v1.0 notes
when they are available for a commit. Though if they are a subset of the
current notes, you would expect to see duplicates. Depending on what you
are storing in your notes, you may want to clean out your notes tree
after the release.

-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: On the behavior of checkout branch with uncommitted local changes

[r . ductor]

Dear Junio,

thanks for your answer and you availability to revise the man text. Below my 
(irreverent) comments

On Thursday 19 September 2013 10:43:16 Junio C Hamano wrote:
 Let's see how we can improve the text.  Points to notice are:
 
  * by updating the index and the files does not say how they are
updated and can be clarified:
 
 - The index is made to match the state the commit at the tip of
   branch records.
 
 - The working tree files without local modifications are updated
   the same way.
 
 - The working tree files with local modifications are not
   touched.

mmm maybe I'm wrong, but it seems to me that the first statement on the index 
(above) is oversimplifing and not correct in presence of local changes. In the 
example below, when in the branch 'dev' the index content was '2 in index' and 
the workspace content was  '3 in work' and the commited contents 
dev:a=master:a='1'. In this case checkout completed and the index (and 
workspace) contents after checkout where preserved, hence the index was 
different from the head commit in both branches master and dev.

$ echo '1'a; git init; git add a; git commit -a -m '1';git checkout -b 
dev;echo '2 in index'a;git add a; echo '3 in work'a; git checkout master; cat 
a; git diff; git diff HEAD 
Initialized empty Git repository in /home//git-test12/.git/ 

[master (root-commit) d0064f1] 1
   
 1 file changed, 1 insertion(+) 
   
 create mode 100644 a   
   
Switched to a new branch 'dev'  
   
M   a   
   
Switched to branch 'master' 
   
3 in work   
   
diff --git a/a b/a  
   
index d35137c..ee9231a 100644   
   
--- a/a 
   
+++ b/a 
   
@@ -1 +1 @@ 
   
-2 in index 
   
+3 in work  
   
diff --git a/a b/a
index d00491f..ee9231a 100644   
   
--- a/a 
   
+++ b/a 
   
@@ -1 +1 @@
-1
+3 in work
$

This is what I ment by  the line if C1=C0, then: W1=W0 and I1=I0;

... am I missing something?


  * Because the command refuses to checkout another branch under
this and that condition does not have its own section, the
description of -m needs to say it as a background information
to explain in what situation the option may be useful.  It can be
moved to the main 'git checkout' branch part and it may make
the result read easier.

I 100% agree that the git checkout' branch should mention that the command 
might not complete in some cases, and hopefully describe when. A normal user 
(me) learning the command tries to first understand the simpler usage before 
going below and learning the action of the options.

 in order to preserve your modifications in context is correct
   and sufficient description

:((( this is one of the points I considered vague... what is context? 
parent commit or parent commit AND index or index? the reader starts to 
asks theirself too much questions, whose aswers requires an educated guess that 
should ideally not be necessary when reading a man page
Maybe I'm to much mathematically minded, but few clean lines of 

Re: [BUG] git clone -q ends with early EOF

[Marek Vasut]

Hi,

 Jeff King p...@peff.net writes:
  The keepalive patch is not in any released version yet, but we have been
  running it in production at GitHub for a few weeks.
 
 That is good to hear; I'd feel safer to bump the scheduled
 graduation date to 'master' for the topic in that case.
 
 Like tomorrow ;-)

I reported the issue on Ubuntu Lunchpad here [1], so I hope they will 
eventually 
fix it.

[1] https://bugs.launchpad.net/ubuntu/+source/git/+bug/1228148

Best regards,
Marek Vasut
--
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] sample pre-commit hook: Use --bool when retrieving config var

[Johan Herland]

Signed-off-by: Johan Herland jo...@herland.net
---
 templates/hooks--pre-commit.sample | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/templates/hooks--pre-commit.sample 
b/templates/hooks--pre-commit.sample
index 586e3bf..68d62d5 100755
--- a/templates/hooks--pre-commit.sample
+++ b/templates/hooks--pre-commit.sample
@@ -16,7 +16,7 @@ else
 fi
 
 # If you want to allow non-ASCII filenames set this variable to true.
-allownonascii=$(git config hooks.allownonascii)
+allownonascii=$(git config --bool hooks.allownonascii)
 
 # Redirect output to stderr.
 exec 12
-- 
1.8.1.rc2.269.g5aaac94

--
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 Plug-in for PowerBuilder

[Kunchur, Ram]

Hello Team,
  We wish to use GITSCC plug-in with PowerBuilder for application 
source-control with GIT GUI, 
We downloaded GitScc.msi setup file from PushOK website, unfortunately when 
file was downloaded and before we could initialize installation
Symantec Endpoint Protection reported the file to be infected was considered to 
be a potential security threat.
Our company security team has denied us from using the above plug-in.

We wish to know is there any alternative plug-in for PowerBuilder-GIT available 
which is secure  safe and also you can suggest us to use it.
Request you to kindly revert and please advise on this matter, Thanks.

Thanks  Best Regards,
Ram Kunchur
Senior Software Engineer
Travelex India Pvt. Ltd.

***
Travelex - www.travelex.com

Travelex India Private Limited is a limited company registered in India
with company number: U 67190 MH 2002PTC.

Information in this email including any attachment ('email') is confidential, 
may be privileged and is intended solely for the addressee. Unauthorised 
recipients are requested to preserve the confidentiality of this email, advise 
the sender immediately of any error in transmission, and then delete the email
from the recipient's mailbox without making copies. Any disclosure, copying, 
distribution or action taken, or omitted to be taken, in reliance upon the 
contents of this email by unauthorised recipients is prohibited and may be
unlawful.

Please note that no contracts or commitments may be concluded on behalf of 
Travelex India Private Limited or its groups of companies ('Travelex') by means
of email, and no statement or representation made in this email is binding on 
behalf of Travelex.

DISCLAIMER: Whilst this message has been scanned for viruses, Travelex 
disclaims any responsibility or liability for viruses contained therein. It is 
therefore recommended that all emails should be scanned for viruses.
***

--
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: breakage in revision traversal with pathspec

[Junio C Hamano]

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

 My original question was going to be: why bother peeling at all if we
 are just going to push the outer objects, anyway?

 And after staring at it, I somehow convinced myself that the answer was
 that you were pushing both. But that is not the case. Sorry for the
 noise.

But that is still a valid point, and the patch to avoid peeling for
non symmetric diff does not look too bad, either.

 revision.c   | 59 ++--
 t/t6000-rev-list-misc.sh |  8 +++
 2 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/revision.c b/revision.c
index 68545c8..7010aff 100644
--- a/revision.c
+++ b/revision.c
@@ -1157,41 +1157,56 @@ int handle_revision_arg(const char *arg_, struct 
rev_info *revs, int flags, unsi
}
if (!get_sha1_committish(this, from_sha1) 
!get_sha1_committish(next, sha1)) {
-   struct commit *a, *b;
-   struct commit_list *exclude;
-
-   a = lookup_commit_reference(from_sha1);
-   b = lookup_commit_reference(sha1);
-   if (!a || !b) {
-   if (revs-ignore_missing)
-   return 0;
-   die(symmetric ?
-   Invalid symmetric difference expression 
%s...%s :
-   Invalid revision range %s..%s,
-   arg, next);
-   }
+   struct object *a_obj, *b_obj;
 
if (!cant_be_filename) {
*dotdot = '.';
verify_non_filename(revs-prefix, arg);
}
 
-   if (symmetric) {
+   a_obj = parse_object(from_sha1);
+   b_obj = parse_object(sha1);
+   if (!a_obj || !b_obj) {
+   missing:
+   if (revs-ignore_missing)
+   return 0;
+   die(symmetric
+   ? Invalid symmetric difference expression 
%s
+   : Invalid revision range %s, arg);
+   }
+
+   if (!symmetric) {
+   /* just A..B */
+   a_flags = flags_exclude;
+   } else {
+   /* A...B -- find merge bases between the two */
+   struct commit *a, *b;
+   struct commit_list *exclude;
+
+   a = (a_obj-type == OBJ_COMMIT
+? (struct commit *)a_obj
+: lookup_commit_reference(a_obj-sha1));
+   b = (b_obj-type == OBJ_COMMIT
+? (struct commit *)b_obj
+: lookup_commit_reference(b_obj-sha1));
+   if (!a || !b)
+   goto missing;
exclude = get_merge_bases(a, b, 1);
add_pending_commit_list(revs, exclude,
flags_exclude);
free_commit_list(exclude);
+
a_flags = flags | SYMMETRIC_LEFT;
-   } else
-   a_flags = flags_exclude;
-   a-object.flags |= a_flags;
-   b-object.flags |= flags;
-   add_rev_cmdline(revs, a-object, this,
+   }
+
+   a_obj-flags |= a_flags;
+   b_obj-flags |= flags;
+   add_rev_cmdline(revs, a_obj, this,
REV_CMD_LEFT, a_flags);
-   add_rev_cmdline(revs, b-object, next,
+   add_rev_cmdline(revs, b_obj, next,
REV_CMD_RIGHT, flags);
-   add_pending_object(revs, a-object, this);
-   add_pending_object(revs, b-object, next);
+   add_pending_object(revs, a_obj, this);
+   add_pending_object(revs, b_obj, next);
return 0;
}
*dotdot = '.';
diff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh
index b10685a..15e3d64 100755
--- a/t/t6000-rev-list-misc.sh
+++ b/t/t6000-rev-list-misc.sh
@@ -48,4 +48,12 @@ test_expect_success 'rev-list --objects with pathspecs and 
copied files' '
! grep one output
 '
 
+test_expect_success 'rev-list A..B and rev-list ^A B are the same' '
+   

Re: [PATCH] t5541: mark passing c-a-s test as success

[Junio C Hamano]

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: sparse checkout file with windows line endings doesn't work

[Junio C Hamano]

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

 On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote:

 When something goes wrong, there appears to be no way to understand what
 git thinks it's reading.   I'm not sure if such a way, if it existed, would 
 help with
 trailing spaces, but if you could say
 
 git read-tree -muv HEAD
 
 and it would say
 
 reading '.git\info\sparse-checkout'...
 rule '/CONFIGURATION ' - no matches

 I don't think you can do that in the general case of read-tree. You may
 have sparse paths that exist in some commits, but not others. As you
 move around in history, a sparse entry that does not match might do so
 because it is poorly written, or it might do so because you just don't
 happen to have any matching paths in the commit you are moving to. The
 former is a problem, but warning on the latter would be useless noise.

While that is very true, if

 (1) there is a good criterion to tell that a path pattern in sparse
 file is very likely to be a mistake; and

 (2) we can guess uniquely what likely-to-be-intended path pattern
 the above is a typo for

it may be reasonable to allow people to do:

GIT_PATH_PATTERN_DEBUG=yes git read-tree -m -u HEAD

and get a diagnostic message

A rule '/CONFIGURATION ' does not match, but would have
matched a path if it were spelled '/CONFIGURATION'

or something like that.  The same applies for exclude and possibly
attribute.

Not my itch, though.  Both of these preconditions are *hard*;
limiting only to trailing whitespaces would be an easy start, but
that limitation would make things pretty much useless on sane
platforms.


--
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] build: add default configuration

[David Aguilar]

Felipe Contreras felipe.contre...@gmail.com wrote:
On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com
wrote:
On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com
wrote:

 Will this not conflict with folks that supply their own gitconfig?

 You mean people that provide their own ETC_GITCONFIG? If you mean
 distributions, their packaging would override /etc/gitconfig, if you
 mean people that have already a /etc/gitconfig, packaging systems
 usually save the old one so they can solve the conflict manually
(e.g.
 /etc/gitconfig.pacsave). So no, it would not conflict.

 Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long
advertised as the way to do it)

You package /etc/gitconfig *outside* the git package? I don't see how
that could have been ever advertised as the way to do it.

Okay so how exactly are we supposed to do it?  Duh, rpm is the right choice for 
redhat systems. 

Users don't package /etc/gitconfig outside git.

Wrong. Existence proof: me. 


 I like the idea. Docs?  Also, should this not be done in the C side
so that we don't waste time reading the config, and also prevent users
from overriding these?

 But we want them to be easily readable, and possibly allow
 distributions to easily modify them.

 In that case I take it back -- I dont like that approach.  We want
consistency, not divergence. This encourages the former.

So you think we have more consistency right now? We don't even have a
predefined /etc/gitconfig, that creates more inconsistency, as
everybody's configs and aliases are very very different.

This patch would definitely make things more consistent.

We don't need this patch to allow distros to modify aliases. Likewise, allowing 
the aliases to diverge is less consistent. Do it at a lower level. 

I also agree with Junio's notes about ci. Something short that can add and 
remove from the index would be nice. 


-- 
David
--
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] format-patch: print in-body From only when needed

[Junio C Hamano]

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

 Commit a908047 taught format-patch the --from option,
 which places the author ident into an in-body from header,
 and uses the committer ident in the rfc822 from header.  The
 documentation claims that it will omit the in-body header
 when it is the same as the rfc822 header, but the code never
 implemented that behavior.

 This patch completes the feature by comparing the two idents
 and doing nothing when they are the same (this is the same
 as simply omitting the in-body header, as the two are by
 definition indistinguishable in this case). This makes it
 reasonable to turn on --from all the time (if it matches
 your particular workflow), rather than only using it when
 exporting other people's patches.

This fix makes 100% sense to me under the assumption that the
--from option is a good idea, but then it makes me wonder why we
need the option in the first place.  What would break if we made
pp-from_ident default to the value of GIT_COMMITTER_IDENT?
--
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

why doesn't git bisect visualize show all commit ids from the bisect log

[Toralf Förster]

When run that command immediate after git bisect start somebody sees
the full commit range as defined in git bisect start.

However running that command later after few git bisect steps somebody
is just presented with the remaining commit interval.

Is this intended ?

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
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: why doesn't git bisect visualize show all commit ids from the bisect log

[Toralf Förster]

On 09/20/2013 08:22 PM, Jonathan Nieder wrote:
 Hi Toralf,
 
 Toralf Förster wrote:
 
 When run that command immediate after git bisect start somebody sees
 the full commit range as defined in git bisect start.

 However running that command later after few git bisect steps somebody
 is just presented with the remaining commit interval.

 Is this intended ?
 
 git bisect visualize is meant as a tool to pin down the culprit
 commit that produced a regression.  Sometimes after a few steps the
 problematic commit is obvious, which can save some test cycles.
 
 If you want to see the list of commits tested so far, git bisect log
 can help.  To see the entire bisection state, even outside the
 regression window, any old gitk foo..bar command will do --- the
 bisection state is kept in bisect/* refs that show up in blue.
 Can you say a little more about what you're trying to do?  Is the goal
 to have a nice visualization of what git bisect log shows?  (I'm not
 aware of any such tool, and I agree it would be a nice thing.)
 
I'm trying to bisect a (bastard of an) issue in fs/dcache.c of the linux
kernel. Till now I do not have a 100% reliable test scenario.

So often I do mark a commit id accidentally wrongly as bad/good.
Therefore git bisect lands into the wrong half. As a consequence all
subsequent bisects are senseless. Visualizing all infos from git bisect
log would help to see such mistakes.

few minutes later

Ick, and now I'm reading your mail again, tried gitk start..end -
that's what I want, thx.
I wasn't aware that gitk uses the info from BISECT_LOG :-)

Knowing this helps me to interrupt a git bisect run ..., restarting my
KDE, continuing the bisecting later and still having the full picture of
the overall git bisect process.

Thx again for clarification.

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
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: why doesn't git bisect visualize show all commit ids from the bisect log

[Jonathan Nieder]

Hi Toralf,

Toralf Förster wrote:

 When run that command immediate after git bisect start somebody sees
 the full commit range as defined in git bisect start.

 However running that command later after few git bisect steps somebody
 is just presented with the remaining commit interval.

 Is this intended ?

git bisect visualize is meant as a tool to pin down the culprit
commit that produced a regression.  Sometimes after a few steps the
problematic commit is obvious, which can save some test cycles.

If you want to see the list of commits tested so far, git bisect log
can help.  To see the entire bisection state, even outside the
regression window, any old gitk foo..bar command will do --- the
bisection state is kept in bisect/* refs that show up in blue.

Can you say a little more about what you're trying to do?  Is the goal
to have a nice visualization of what git bisect log shows?  (I'm not
aware of any such tool, and I agree it would be a nice thing.)

Hope that helps,
Jonathan
--
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] format-patch: print in-body From only when needed

[Jeff King]

On Fri, Sep 20, 2013 at 11:17:45AM -0700, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  Commit a908047 taught format-patch the --from option,
  which places the author ident into an in-body from header,
  and uses the committer ident in the rfc822 from header.  The
  documentation claims that it will omit the in-body header
  when it is the same as the rfc822 header, but the code never
  implemented that behavior.
 
  This patch completes the feature by comparing the two idents
  and doing nothing when they are the same (this is the same
  as simply omitting the in-body header, as the two are by
  definition indistinguishable in this case). This makes it
  reasonable to turn on --from all the time (if it matches
  your particular workflow), rather than only using it when
  exporting other people's patches.
 
 This fix makes 100% sense to me under the assumption that the
 --from option is a good idea, but then it makes me wonder why we
 need the option in the first place.  What would break if we made
 pp-from_ident default to the value of GIT_COMMITTER_IDENT?

Anything consuming format-patch output that does not understand in-body
headers would be broken.

I think rebase would be safe, because it uses git-am under the hood, so
in theory it is a noop.

send-email would have to learn to parse the in-body header, for two
reasons:

  1. We cannot get rid of send-email's in-body header writing, because
 we would want to handle patches generated (or munged) outside of
 format-patch, and because send-email has its own --from option
 and sendemail.from configuration.

 If that config matches the committer, it should be a noop. If it
 doesn't, we have we have two cases:

   a. There is no in-body header. We promote the rfc822 header to an
  in-body one, and add our configured from as the rfc822
  header.

   b. There is an in-body header. We leave it intact, but throw away
  the current rfc822 header and replace it with our configured
  header.

  2. send-email does header magic like auto-adding cc's, and suppressing
 addresses found in other headers. It would need (at least) to pick
 out the author from the in-body header to cc.

The patch below turns the feature on all the time. There are test
breakages in in t9001, t3901, t4014, and t4013. The last 3 I think are
just cosmetic. t9001 has a ton of breakages around the header
suppressions, but I didn't analyze which ones were just this should now
read 'committer' instead of 'author' and which ones represented real
breakage.

So I think it should be possible to fix our internal consumers of
format-patch output to handle this. And certainly there are some
external consumers that would be made more happy (i.e., anything that is
planning to actually send the output as an email). But I'm a little wary
of external consumers that might get confused by it. I think we'd want
to flip it at a major version boundary, at least.

-Peff

---
diff --git a/builtin/log.c b/builtin/log.c
index 77d0f5f..77564fd 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1235,6 +1235,8 @@ int cmd_format_patch(int argc, const char **argv, const 
char *prefix)
rev.no_inline = 1;
}
 
+   from = xstrdup(git_committer_info(IDENT_NO_DATE));
+
/*
 * Parse the arguments before setup_revisions(), or something
 * like git format-patch -o a123 HEAD^.. may fail; a123 is
--
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] format-patch: print in-body From only when needed

[Junio C Hamano]

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

 So I think it should be possible to fix our internal consumers 
 ... I'm a little wary
 of external consumers that might get confused by it.

Yeah, thanks for a good summary of analysis.  I agree that it would
be doable, but it is dubious if it is worth it.


 ---
 diff --git a/builtin/log.c b/builtin/log.c
 index 77d0f5f..77564fd 100644
 --- a/builtin/log.c
 +++ b/builtin/log.c
 @@ -1235,6 +1235,8 @@ int cmd_format_patch(int argc, const char **argv, const 
 char *prefix)
   rev.no_inline = 1;
   }
  
 + from = xstrdup(git_committer_info(IDENT_NO_DATE));
 +
   /*
* Parse the arguments before setup_revisions(), or something
* like git format-patch -o a123 HEAD^.. may fail; a123 is
--
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] build: add default configuration

[Felipe Contreras]

David Aguilar wrote:
 Felipe Contreras felipe.contre...@gmail.com wrote:
 On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com
 wrote:
 On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com
 wrote:
 
  Will this not conflict with folks that supply their own gitconfig?
 
  You mean people that provide their own ETC_GITCONFIG? If you mean
  distributions, their packaging would override /etc/gitconfig, if you
  mean people that have already a /etc/gitconfig, packaging systems
  usually save the old one so they can solve the conflict manually
 (e.g.
  /etc/gitconfig.pacsave). So no, it would not conflict.
 
  Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long
 advertised as the way to do it)
 
 You package /etc/gitconfig *outside* the git package? I don't see how
 that could have been ever advertised as the way to do it.
 
 Okay so how exactly are we supposed to do it?  Duh, rpm is the right choice 
 for redhat systems. 

The same way kerberos, mariadb, apache, and essentially every other tool that
has a configuration file in /etc.

 Users don't package /etc/gitconfig outside git.
 
 Wrong. Existence proof: me. 

You as a user are not packaging it, it's you as a system adimistrator. Either
way, you are 0.0001% of Git's userbase, you are not representative.

  I like the idea. Docs?  Also, should this not be done in the C side
 so that we don't waste time reading the config, and also prevent users
 from overriding these?
 
  But we want them to be easily readable, and possibly allow
  distributions to easily modify them.
 
  In that case I take it back -- I dont like that approach.  We want
 consistency, not divergence. This encourages the former.
 
 So you think we have more consistency right now? We don't even have a
 predefined /etc/gitconfig, that creates more inconsistency, as
 everybody's configs and aliases are very very different.
 
 This patch would definitely make things more consistent.
 
 We don't need this patch to allow distros to modify aliases. Likewise, 
 allowing the aliases to diverge is less consistent. Do it at a lower level. 

We already allow the aliases to diverge, we allow it much more.

The pach will make the aliases more consistent.

 I also agree with Junio's notes about ci. Something short that can add and 
 remove from the index would be nice. 

cvs ci, svn ci, hg ci, they all work, but suddenly ci is not good enough for 
Git? Yeah, sure.

-- 
Felipe Contreras
--
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 Plug-in for PowerBuilder

[Robin Rosenberg]

- Ursprungligt meddelande -
 Från: Ram Kunchur ram.kunc...@travelex.com
 Till: git@vger.kernel.org
 Kopia: Daren Scott daren.sc...@travelex.com, Rajen Shah 
 rajen.s...@travelex.com, Sagar Keluskar
 sagar.kelus...@travelex.com
 Skickat: fredag, 20 sep 2013 16:17:38
 Ämne: GIT Plug-in for PowerBuilder
 
 Hello Team,
   We wish to use GITSCC plug-in with PowerBuilder for application
   source-control with GIT GUI,
 We downloaded GitScc.msi setup file from PushOK website, unfortunately when
 file was downloaded and before we could initialize installation
 Symantec Endpoint Protection reported the file to be infected was considered
 to be a potential security threat.
 Our company security team has denied us from using the above plug-in.
 
 We wish to know is there any alternative plug-in for PowerBuilder-GIT
 available which is secure  safe and also you can suggest us to use it.
 Request you to kindly revert and please advise on this matter, Thanks.

That's the only one I know of. Fortunately, since Git does not lock files, you
really don't need a plugin. Just run git gui side by side with your IDE and
you'll be fine.

I asked PushOK about that plugin a long time ago and they did not support it.
Now it seems they forgot they have the web site, hence the extras included.

-- robin
--
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 (Sep 2013, #06; Fri, 20)

[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 fifth batch of topics are in 'master'.  We are about to pass 350
non-merge commits since the last release, which means we are halfway
there for the next release.  Among ~60 contributors who have commits
in the 'master' branch since v1.8.4, ~10 are new faces.

I'll be offline starting next week for a few weeks; in order to
improve the bus factor, I asked Jonathan Nieder to fill in for me
as the interim maintainer, with Peff as a back-up.

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]

* bc/http-backend-allow-405 (2013-09-12) 1 commit
  (merged to 'next' on 2013-09-12 at bc1719f)
 + http-backend: provide Allow header for 405

 When the webserver responds with 405 Method Not Allowed, it
 should tell the client what methods are allowed with the Allow
 header.


* bk/refs-multi-update (2013-09-11) 8 commits
  (merged to 'next' on 2013-09-13 at e6d21af)
 + update-ref: add test cases covering --stdin signature
 + update-ref: support multiple simultaneous updates
 + refs: add update_refs for multiple simultaneous updates
 + refs: add function to repack without multiple refs
 + refs: factor delete_ref loose ref step into a helper
 + refs: factor update_ref steps into helpers
 + refs: report ref type from lock_any_ref_for_update
 + reset: rename update_refs to reset_refs

 Give update-refs a --stdin option to read multiple update
 requests and perform them in an all-or-none fashion.


* dw/check-ignore-sans-index (2013-09-12) 1 commit
  (merged to 'next' on 2013-09-13 at 8daec3c)
 + check-ignore: Add option to ignore index contents

 git check-ignore follows the same rule as git add and git
 status in that the ignore/exclude mechanism does not take effect
 on paths that are already tracked.  With --no-index option, it
 can be used to diagnose which paths that should have been ignored
 have been mistakenly added to the index.


* fc/at-head (2013-09-12) 2 commits
  (merged to 'next' on 2013-09-13 at d3800c2)
 + Add new @ shortcut for HEAD
 + sha1-name: pass len argument to interpret_branch_name()

 Attempt to resurrect Type @ for HEAD; the bottom one seems to be
 a genuine code improvement, but identifying cases where @ means
 HEAD were harder than it should have been.  I think the result of
 squashing the tip one in covers all the necessary cases.


* hu/cherry-pick-previous-branch (2013-09-09) 1 commit
  (merged to 'next' on 2013-09-12 at 36e4d9b)
 + cherry-pick: allow - as abbreviation of '@{-1}'

 Just like git checkout - knows to check out and git merge -
 knows to merge the branch you were previously on, teach git
 cherry-pick to understand - as the previous branch.


* jh/checkout-auto-tracking (2013-09-17) 6 commits
  (merged to 'next' on 2013-09-17 at 6748f49)
 + t3200: fix failure on case-insensitive filesystems
  (merged to 'next' on 2013-09-13 at 2aa1553)
 + branch.c: Relax unnecessary requirement on upstream's remote ref name
 + t3200: Add test demonstrating minor regression in 41c21f2
 + Refer to branch.name.remote/merge when documenting --track
 + t3200: Minor fix when preparing for tracking failure
 + t2024: Fix -chaining and a couple of typos

 Fix a minor regression in v1.8.3.2 and later that made it
 impossible to base your local work on anything but a local branch
 of the upstream repository you are tracking from.


* jk/upload-pack-keepalive (2013-09-09) 2 commits
  (merged to 'next' on 2013-09-17 at d3141ac)
 + upload-pack: bump keepalive default to 5 seconds
 + upload-pack: send keepalive packets during pack computation

 When running fetch -q, a long silence while the sender side
 computes the set of objects to send can be mistaken by proxies as
 dropped connection.


* jx/branch-vv-always-compare-with-upstream (2013-08-26) 2 commits
  (merged to 'next' on 2013-09-12 at b5c37f4)
 + status: always show tracking branch even no change
 + branch: report invalid tracking branch as gone

 git branch -v -v (and git status) did not distinguish among a
 branch that does not build on any other branch, a branch that is in
 sync with the branch it builds on, and a branch that is configured
 to build on some other branch that no longer exists.


* mm/commit-template-squelch-advice-messages (2013-09-12) 3 commits
  (merged to 'next' on 2013-09-13 at 410d207)
 + commit: disable status hints when writing to COMMIT_EDITMSG
 + wt-status: turn advice_status_hints into a field of wt_status
 + commit: factor status configuration is a helper function

 From the commit log template, remove irrelevant advice messages
 that are shared with git status output.


* mm/rebase-continue-freebsd-WB (2013-09-09) 1 commit
  (merged to 'next' on 2013-09-13 at 82e8b91)
 + rebase: fix 

Re: [PATCH 2/2] perf-lib: add test_perf_cleanup target

[Thomas Gummerer]

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

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

 Thomas Gummerer t.gumme...@gmail.com writes:

 When one performance test fails, the testing is aborted and the cleanup
 commands are not executed anymore, leaving the trash directory in the
 failed state.

 Ah, that I overlooked. In that case, the comments in my previous
 message do not apply.

 Having said that, it was unclear to me why we would want a new
 test_perf_cleanup added.

 The name is misleading (does it define only clean-up actions?) to
 say the least, and one way of fixing it would be to call it
 test_perf_with_cleanup.

It defines any actions you want to happen after each round of tests that
should not be timed.  Usually that would mean any action that resets a
modified repository to its original state.  I'm not really sure about
the name, but test_perf_with_cleanup seems good to me.

 I wondered why this clean-up section cannot be an optional parameter
 to test_perf, but that would not fly well because we won't know if
 3-arg form is with one prerequisite and no clean-up, or no prereq
 with a clean-up, so perhaps adding a new function may be the best
 you could do.

Yeah, that was my first thought too, but as you explained that's not
possible.  Just thinking out loud, we could drop the prerequisite check
for performance tests, as no performance tests currently use it.  Future
performance tests may use it though and it would be inconsistent with
the rest of the test-suite.

 But in the longer term, I think we would be better off to allow two
 styles (one traditional, another modern) and add new features only
 to the modern (aka more easily extensible) form:

   test_perf [PREREQ] BODY
   test_perf [--prereq PREREQ] [--cleanup CLEANUP] ... BODY

 perhaps like this (this is without --cleanup but it should be
 obvious how to add a support for it to the command line parser).

I think this makes most sense.  The cleanup part would only be needed
for the perf tests, but the flexibility of this wouldn't hurt.  The
cleanup would then look something like this:

diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index b2a277b..4dfdd28 100644
--- a/t/perf/perf-lib.sh
+++ b/t/perf/perf-lib.sh
@@ -176,6 +176,21 @@ test_perf () {
test_failure_ $@
break
fi
+   if ! test -z $cleanup_action; then
+   say 3 cleaning up: $cleanup_action
+   if test_run_ $cleanup_action
+   then
+   if test -z $verbose; then
+   echo -n  c$i
+   else
+   echo * cleaning up run 
$i/$GIT_PERF_REPEAT_COUNT:
+   fi
+   else
+   test -z $verbose  echo
+   test_failure_ $@
+   break
+   fi
+   fi
done
if test -z $verbose; then
echo  ok
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 473b21d..4bad14f 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -360,6 +360,12 @@ test_expect_parse () {
test_prereq=$2
shift
;;
+   --cleanup)
+   test $# -gt 1 ||
+   error bug in the test script: --cleanup needs a 
parameter
+   cleanup_action=$2
+   shift
+   ;;
--)
shift
break

I'll try to send an updated patch series, probably over the weekend with
this suggestions included (It's time to go to bed now).

 The patch to t0008 is primarily to adjust for test labels that begin
 with double-dashes that will be mistaken as a new-style option, but
 it is unnecessarily big because it uses random custom shell functions
 to hide the real calls to underlying test_expect_success X-.


  t/test-lib-functions.sh | 72 
 ++---
  t/perf/perf-lib.sh  | 17 +---
  t/t0008-ignores.sh  | 43 +++--
  3 files changed, 87 insertions(+), 45 deletions(-)

 diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
 index a7e9aac..10202dc 100644
 --- a/t/test-lib-functions.sh
 +++ b/t/test-lib-functions.sh
 @@ -342,20 +342,65 @@ test_declared_prereq () {
   return 1
  }

 +test_expect_parse () {
 + whoami=$1
 + shift
 + test_expect_new_style=
 + while case $# in 0) false ;; esac
 + do
 + case $1 in
 + --prereq)
 + test $# -gt 1 

Re: What's cooking in git.git (Sep 2013, #02; Mon, 9)

[Junio C Hamano]

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

 Am 10.09.2013 00:53, schrieb Junio C Hamano:
 * bc/submodule-status-ignored (2013-09-04) 2 commits
  - submodule: don't print status output with ignore=all
  - submodule: fix confusing variable name
 
  Originally merged to 'next' on 2013-08-22
 
  Will merge to 'next'.

 I propose to cook this some time in next to give submodule
 users who have configured ignore=all the opportunity to test
 and comment on that. And as Matthieu noticed the documentation
 is not terribly clear here, I'll prepare one or two patches to
 fix that which should go in together with these changes.

The patches are still in 'next' but I think with the documentation
update you and Matthieu did, it should be ready to be in 'master'
now, 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: Local tag killer

[Junio C Hamano]

Junio C Hamano gitster-v...@pobox.com writes:

 I also agree that the documentation is misstated; remote-tracking branch
 may have been a convenient and well understood phrase for whoever wrote
 that part, but the --prune is designed to cull extra refs in the
 hierarchies into
 which refs would be fetched if counterparts existed on the other side, so
 culling tags that do not exist on the remote side should also be described.

(gleaning-leftovers mode)


 Documentation/fetch-options.txt | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index ba1fe49..a6c581b 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -41,8 +41,20 @@ ifndef::git-pull[]
 
 -p::
 --prune::
-   After fetching, remove any remote-tracking branches which
-   no longer exist on the remote.
+
+   After fetching, remove any local ref that was not updated
+   only because the remote ref that was supposed to update it
+   was missing.
++
+For example, `git fetch origin refs/heads/*:refs/remotes/origin/*`
+tries to update local `refs/remotes/origin/frotz` if `origin` has
+`refs/heads/frotz`.  With this option, `refs/remotes/origin/frotz`
+will be removed from our repository if `origin` does not have
+`refs/heads/frotz`.
++
+This is used to remove remote-tracking branches which no longer
+exist on the remote.
+
 endif::git-pull[]
 
 ifdef::git-pull[]
--
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: [BUG?] git checkout $commit -- somedir doesn't drop files

[Junio C Hamano]

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

  But I think that points to a larger problem, which is that we do
  not want to just look at the entries that are different between the
  tree and the index.

True.  The unpack-trees API knows how to walk the index and trees in
parallel, and I tend to agree that it may be a more suitable vehicle
for this purpose.
--
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 the behavior of checkout branch with uncommitted local changes

[Junio C Hamano]

r.duc...@gmail.com writes:

 mmm maybe I'm wrong, but it seems to me that the first statement
 on the index (above) is oversimplifing.

Yes, it was simplified to illustrate the principle, not even trying
to be exhaustive.

The principle is that we allow you to check out a different branch
when you have local changes to the working tree and/or to the index,
as long as we can make the index and the working tree pretend as if
you reached that locally modified state, starting from a clean state
of the branch you are checking out.

That is what your modifications in context in the description of
the -m option refers to.

It directly follows that a local change to the index at a path is
carried forward when you check out a different branch, if HEAD and
the branch you are checking out have the same contents registered at
the path.

The message you are responding to illustrated that principle by
talking about changes to the working tree but the same principle
applies to changes to the index, as changes to the working tree is
much easier to picture in your mind.
--
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] build: add default configuration

[David Aguilar]

Felipe Contreras felipe.contre...@gmail.com wrote:
David Aguilar wrote:
 Felipe Contreras felipe.contre...@gmail.com wrote:
 On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com
 wrote:
 On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com
 wrote:
 
  Will this not conflict with folks that supply their own
gitconfig?
 
  You mean people that provide their own ETC_GITCONFIG? If you mean
  distributions, their packaging would override /etc/gitconfig, if
you
  mean people that have already a /etc/gitconfig, packaging systems
  usually save the old one so they can solve the conflict manually
 (e.g.
  /etc/gitconfig.pacsave). So no, it would not conflict.
 
  Yuck. Yes, that one. I package my own /etc/gitconfig (as we have
long
 advertised as the way to do it)
 
 You package /etc/gitconfig *outside* the git package? I don't see
how
 that could have been ever advertised as the way to do it.
 
 Okay so how exactly are we supposed to do it?  Duh, rpm is the right
choice for redhat systems. 

The same way kerberos, mariadb, apache, and essentially every other
tool that
has a configuration file in /etc.

Good point. These tools (apache, for example) allow inclusion of a directory. 
Users are encouraged to package their stuff inside eg httpd.d/, and the distros 
ship a neutral config that includes that directory. 

Your patch does not add this capability, so by your own definition it's 
incomplete.  As-is, the patch is half-baked.

If we have a clear upgrade path -- eg move your current configs over to 
/etc/git.d/your.conf -- then it's a non-issue. 

As-is, you're asking users to manually deal with the fallout. You're also 
asking users to modify a package-manager controlled file (after your patch), 
which IMO is suboptimal. 


 Users don't package /etc/gitconfig outside git.
 
 Wrong. Existence proof: me. 

You as a user are not packaging it, it's you as a system adimistrator.

Strawman. I represent at least at least a hundred users, but who cares. It 
doesn't matter.  The patch is incomplete. 

Either
way, you are 0.0001% of Git's userbase, you are not representative.

And your point is what exactly?  That once proven wrong you move the goalposts?


  I like the idea. Docs?  Also, should this not be done in the C
side
 so that we don't waste time reading the config, and also prevent
users
 from overriding these?
 
  But we want them to be easily readable, and possibly allow
  distributions to easily modify them.
 
  In that case I take it back -- I dont like that approach.  We want
 consistency, not divergence. This encourages the former.
 
 So you think we have more consistency right now? We don't even have
a
 predefined /etc/gitconfig, that creates more inconsistency, as
 everybody's configs and aliases are very very different.
 
 This patch would definitely make things more consistent.
 
 We don't need this patch to allow distros to modify aliases.
Likewise, allowing the aliases to diverge is less consistent. Do it at
a lower level. 

We already allow the aliases to diverge, we allow it much more.

The pach will make the aliases more consistent.

 I also agree with Junio's notes about ci. Something short that can
add and remove from the index would be nice. 

cvs ci, svn ci, hg ci, they all work, but suddenly ci is not good
enough for Git? Yeah, sure.

IMO this isn't the kind of thing that you or I can decide in isolation.  Maybe 
it is, or maybe the real differences between the ci mental model are enough 
that it isn't. But you don't actually know the answer. You might think you do, 
but your guess is just as good/bad/ugly as mine. 

-- 
David
--
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] warn about http server document being too old

[Sitaram Chamarty]

  - describe when it is still applicable
  - tell people where to go for most normal cases

Signed-off-by: Sitaram Chamarty sita...@atc.tcs.com
---

ref: http://thread.gmane.org/gmane.comp.version-control.git/159633.  Yes
it's very old but better late than never.

 Documentation/howto/setup-git-server-over-http.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/howto/setup-git-server-over-http.txt 
b/Documentation/howto/setup-git-server-over-http.txt
index 7f4943e..90b19a0 100644
--- a/Documentation/howto/setup-git-server-over-http.txt
+++ b/Documentation/howto/setup-git-server-over-http.txt
@@ -3,6 +3,11 @@ Subject: Setting up a Git repository which can be pushed into 
and pulled from ov
 Date: Thu, 10 Aug 2006 22:00:26 +0200
 Content-type: text/asciidoc

+NOTE: This document is from 2006.  A lot has happened since then, and this
+document is now relevant mainly if your web host is not CGI capable.
+
+Almost everyone else should instead look at linkgit:git-http-backend[1].
+
 How to setup Git server over http
 =

-- 
1.8.3.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] build: add default configuration

[Felipe Contreras]

On Fri, Sep 20, 2013 at 7:44 PM, David Aguilar dav...@gmail.com wrote:
 Felipe Contreras felipe.contre...@gmail.com wrote:
David Aguilar wrote:
 Felipe Contreras felipe.contre...@gmail.com wrote:
 On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com
 wrote:
 On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com
 wrote:
 
  Will this not conflict with folks that supply their own
gitconfig?
 
  You mean people that provide their own ETC_GITCONFIG? If you mean
  distributions, their packaging would override /etc/gitconfig, if
you
  mean people that have already a /etc/gitconfig, packaging systems
  usually save the old one so they can solve the conflict manually
 (e.g.
  /etc/gitconfig.pacsave). So no, it would not conflict.
 
  Yuck. Yes, that one. I package my own /etc/gitconfig (as we have
long
 advertised as the way to do it)
 
 You package /etc/gitconfig *outside* the git package? I don't see
how
 that could have been ever advertised as the way to do it.

 Okay so how exactly are we supposed to do it?  Duh, rpm is the right
choice for redhat systems.

The same way kerberos, mariadb, apache, and essentially every other
tool that
has a configuration file in /etc.

 Good point. These tools (apache, for example) allow inclusion of a directory.

Wrong. Apache does, but neither does kerberos, nor mariadb, which have
a single configuration file, at least on all the systems I've seen.

You act as if you have never seen .pacsave/.rpmsave (and so on) files
before, they a are pretty common sight when the user modifies the
configuration files, and as kerberos and mariadb demonstrate, pretty
successful projects can survive with a simple single configuration
file.

 Your patch does not add this capability, so by your own definition it's 
 incomplete.  As-is, the patch is half-baked.

It's not incomplete, any more than kerberos, mariadb, and countless
other programs are.

 If we have a clear upgrade path -- eg move your current configs over to 
 /etc/git.d/your.conf -- then it's a non-issue.

But now you contradict yourself. This patch would force users to
resolve the conflicts eventually through .pacsave/.rpmsave, and with
your proposal to have directory includes, it would also force manual
user intervention by moving the configuration files and resolve the
conflict.

So why is one manual user intervention so appalling, and the other one so right?

Either way, if this patch is so wrong, then clearly the RedHat
packaging team would remove /etc/gitconfig from the Git RPM package,
and you would be fine, wouldn't you?

Or maybe you are afraid that RedHat packaging team would agree that
the /etc/gitconfig file provided by Git is fine.

 As-is, you're asking users to manually deal with the fallout. You're also 
 asking users to modify a package-manager controlled file (after your patch), 
 which IMO is suboptimal.

In both cases the user has to manually deal with the fallout.

 Users don't package /etc/gitconfig outside git.

 Wrong. Existence proof: me.

You as a user are not packaging it, it's you as a system adimistrator.

 Strawman. I represent at least at least a hundred users, but who cares. It 
 doesn't matter.  The patch is incomplete.

No you don't, you represent a system administrator, not a user.

Either
way, you are 0.0001% of Git's userbase, you are not representative.

 And your point is what exactly?  That once proven wrong you move the 
 goalposts?

It's called colloquial language. If I say, people don't bark on the
street, and then you say here, there's a guy that does bark on the
street, and then I say, fine, people don't *NORMALLY* bark on the
street, what have we achieved?

This is just an exercise in pedanticism.

Sane users, under normal circumstances, for the overwhelmingly vast
majority of situations, do not package their /etc/gitconfig file.

  I like the idea. Docs?  Also, should this not be done in the C
side
 so that we don't waste time reading the config, and also prevent
users
 from overriding these?
 
  But we want them to be easily readable, and possibly allow
  distributions to easily modify them.
 
  In that case I take it back -- I dont like that approach.  We want
 consistency, not divergence. This encourages the former.
 
 So you think we have more consistency right now? We don't even have
a
 predefined /etc/gitconfig, that creates more inconsistency, as
 everybody's configs and aliases are very very different.
 
 This patch would definitely make things more consistent.

 We don't need this patch to allow distros to modify aliases.
Likewise, allowing the aliases to diverge is less consistent. Do it at
a lower level.

We already allow the aliases to diverge, we allow it much more.

The pach will make the aliases more consistent.

 I also agree with Junio's notes about ci. Something short that can
add and remove from the index would be nice.

cvs ci, svn ci, hg ci, they all work, but suddenly ci is not good
enough for Git? Yeah, sure.

 IMO this isn't the kind of