[PATCH 4/8] reflog: fix documentation

2015-02-09 Thread Michael Haggerty 
Update the git reflog usage documentation in the manpage and the
command help to match the current reality.

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
 Documentation/git-reflog.txt | 6 --
 builtin/reflog.c | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 70791b9..b410ee6 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -17,9 +17,11 @@ The command takes various subcommands, and different options
 depending on the subcommand:
 
 [verse]
-'git reflog expire' [--dry-run] [--stale-fix] [--verbose]
+'git reflog expire' [--dry-run] [--verbose]
+   [--rewrite] [--updateref] [--stale-fix]
[--expire=time] [--expire-unreachable=time] [--all] refs...
-'git reflog delete' ref@\{specifier\}...
+'git reflog delete' [--dry-run] [--verbose]
+   [--rewrite] [--updateref] ref@\{specifier\}...
 'git reflog' ['show'] [log-options] [ref]
 
 Reflog is a mechanism to record when the tip of branches are
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 49c64f9..d89a6dd 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -13,7 +13,7 @@
  */
 
 static const char reflog_expire_usage[] =
-git reflog expire [--verbose] [--dry-run] [--stale-fix] [--expire=time] 
[--expire-unreachable=time] [--all] refs...;
+git reflog expire [--verbose] [--dry-run] [--rewrite] [--updateref] 
[--stale-fix] [--expire=time] [--expire-unreachable=time] [--all] 
refs...;
 static const char reflog_delete_usage[] =
 git reflog delete [--verbose] [--dry-run] [--rewrite] [--updateref] 
refs...;
 
-- 
2.1.4

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

[PATCH 3/8] lock_ref_sha1_basic(): do not set force_write for missing references

2015-02-09 Thread Michael Haggerty 
If a reference is missing, its SHA-1 will be null_sha1, which can't
possibly match a new value that ref_transaction_commit() is trying to
update it to. So there is no need to set force_write in this scenario.

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
 refs.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/refs.c b/refs.c
index 651e37e..b083858 100644
--- a/refs.c
+++ b/refs.c
@@ -2259,7 +2259,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char 
*refname,
int type, lflags;
int mustexist = (old_sha1  !is_null_sha1(old_sha1));
int resolve_flags = 0;
-   int missing = 0;
int attempts_remaining = 3;
 
lock = xcalloc(1, sizeof(struct ref_lock));
@@ -2298,13 +2297,13 @@ static struct ref_lock *lock_ref_sha1_basic(const char 
*refname,
orig_refname, strerror(errno));
goto error_return;
}
-   missing = is_null_sha1(lock-old_sha1);
-   /* When the ref did not exist and we are creating it,
-* make sure there is no existing ref that is packed
-* whose name begins with our refname, nor a ref whose
-* name is a proper prefix of our refname.
+   /*
+* When the ref did not exist and we are creating it, make
+* sure there is no existing packed ref whose name begins with
+* our refname, nor a packed ref whose name is a proper prefix
+* of our refname.
 */
-   if (missing 
+   if (is_null_sha1(lock-old_sha1) 
 !is_refname_available(refname, skip, get_packed_refs(ref_cache))) 
{
last_errno = ENOTDIR;
goto error_return;
@@ -2320,8 +2319,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char 
*refname,
lock-ref_name = xstrdup(refname);
lock-orig_ref_name = xstrdup(orig_refname);
ref_file = git_path(%s, refname);
-   if (missing)
-   lock-force_write = 1;
if ((flags  REF_NODEREF)  (type  REF_ISSYMREF))
lock-force_write = 1;
 
-- 
2.1.4

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

[PATCH 7/8] reflog_expire(): never update a reference to null_sha1

2015-02-09 Thread Michael Haggerty 
Currently, if --updateref is specified and the very last reflog entry
is expired or deleted, the reference's value is set to 0{40}. This is
an invalid state of the repository, and breaks, for example, git
fsck and git for-each-ref.

The only place we use --updateref in our own code is when dropping
stash entries. In that code, the very next step is to check if the
reflog has been made empty, and if so, delete the refs/stash
reference entirely. Thus that code path ultimately leaves the
repository in a valid state.

But we don't want the repository in an invalid state even temporarily,
and we don't want leave an invalid state if other callers of git
reflog expire|delete --updateref don't think to do the extra cleanup
step.

So, if git reflog expire|delete leaves no more entries in the
reflog, just leave the reference un-updated.

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Another alternative would be to delete the reference in this
situation. This behavior would be kindof logically consistent and
happens to be just the thing that git stash drop wants. It wouldn't
even really be backwards-incompatible, given that the current code
leaves a broken repository in this situation. However, this change
would require some special casing if the reference whose reflog is
being expired is the current reference, and it somehow seems too
lossy to me for some reason. I'm open to feedback on this point.

 refs.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/refs.c b/refs.c
index c0001da..1b2a497 100644
--- a/refs.c
+++ b/refs.c
@@ -4077,10 +4077,13 @@ int reflog_expire(const char *refname, const unsigned 
char *sha1,
/*
 * It doesn't make sense to adjust a reference pointed
 * to by a symbolic ref based on expiring entries in
-* the symbolic reference's reflog.
+* the symbolic reference's reflog. Nor can we update
+* a reference if there are no remaining reflog
+* entries.
 */
int update = (flags  EXPIRE_REFLOGS_UPDATE_REF) 
-   ~(type  REF_ISSYMREF);
+   ~(type  REF_ISSYMREF) 
+   !is_null_sha1(cb.last_kept_sha1);
 
if (close_lock_file(reflog_lock)) {
status |= error(couldn't write %s: %s, log_file,
-- 
2.1.4

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

[PATCH 5/8] reflog: rearrange the manpage

2015-02-09 Thread Michael Haggerty 
Rearrange the git reflog manpage to list more common operations
earlier.

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
 Documentation/git-reflog.txt | 56 ++--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index b410ee6..f15a48e 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -17,21 +17,21 @@ The command takes various subcommands, and different options
 depending on the subcommand:
 
 [verse]
+'git reflog' ['show'] [log-options] [ref]
 'git reflog expire' [--dry-run] [--verbose]
[--rewrite] [--updateref] [--stale-fix]
[--expire=time] [--expire-unreachable=time] [--all] refs...
 'git reflog delete' [--dry-run] [--verbose]
[--rewrite] [--updateref] ref@\{specifier\}...
-'git reflog' ['show'] [log-options] [ref]
 
-Reflog is a mechanism to record when the tip of branches are
-updated.  This command is to manage the information recorded in it.
+Reflog is a mechanism to record when the tips of branches are updated.
+The reflog is useful in various Git commands, to specify the old value
+of a reference. For example, `HEAD@{2}` means where HEAD used to be
+two moves ago, `master@{one.week.ago}` means where master used to
+point to one week ago, and so on. See linkgit:gitrevisions[7] for
+more details.
 
-The subcommand expire is used to prune older reflog entries.
-Entries older than `expire` time, or entries older than
-`expire-unreachable` time and not reachable from the current
-tip, are removed from the reflog.  This is typically not used
-directly by the end users -- instead, see linkgit:git-gc[1].
+This command manages the information recorded in the reflog.
 
 The subcommand show (which is also the default, in the absence of any
 subcommands) will take all the normal log options, and show the log of
@@ -40,11 +40,11 @@ The reflog will cover all recent actions (HEAD reflog 
records branch switching
 as well).  It is an alias for `git log -g --abbrev-commit --pretty=oneline`;
 see linkgit:git-log[1].
 
-The reflog is useful in various Git commands, to specify the old value
-of a reference. For example, `HEAD@{2}` means where HEAD used to be
-two moves ago, `master@{one.week.ago}` means where master used to
-point to one week ago, and so on. See linkgit:gitrevisions[7] for
-more details.
+The subcommand expire is used to prune older reflog entries.
+Entries older than `expire` time, or entries older than
+`expire-unreachable` time and not reachable from the current
+tip, are removed from the reflog.  This is typically not used
+directly by the end users -- instead, see linkgit:git-gc[1].
 
 To delete single entries from the reflog, use the subcommand delete
 and specify the _exact_ entry (e.g. `git reflog delete master@{2}`).
@@ -53,19 +53,6 @@ and specify the _exact_ entry (e.g. `git reflog delete 
master@{2}`).
 OPTIONS
 ---
 
---stale-fix::
-   This revamps the logic -- the definition of broken commit
-   becomes: a commit that is not reachable from any of the refs and
-   there is a missing object among the commit, tree, or blob
-   objects reachable from it that is not reachable from any of the
-   refs.
-+
-This computation involves traversing all the reachable objects, i.e. it
-has the same cost as 'git prune'.  Fortunately, once this is run, we
-should not have to ever worry about missing objects, because the current
-prune and pack-objects know about reflogs and protect objects referred by
-them.
-
 --expire=time::
Entries older than this time are pruned.  Without the
option it is taken from configuration `gc.reflogExpire`,
@@ -83,8 +70,18 @@ them.
turns off early pruning of unreachable entries (but see
--expire).
 
---all::
-   Instead of listing refs explicitly, prune all refs.
+--stale-fix::
+   This revamps the logic -- the definition of broken commit
+   becomes: a commit that is not reachable from any of the refs and
+   there is a missing object among the commit, tree, or blob
+   objects reachable from it that is not reachable from any of the
+   refs.
++
+This computation involves traversing all the reachable objects, i.e. it
+has the same cost as 'git prune'.  Fortunately, once this is run, we
+should not have to ever worry about missing objects, because the current
+prune and pack-objects know about reflogs and protect objects referred by
+them.
 
 --updateref::
Update the ref with the sha1 of the top reflog entry (i.e.
@@ -98,6 +95,9 @@ them.
 --verbose::
Print extra information on screen.
 
+--all::
+   Instead of listing refs explicitly, prune all refs.
+
 GIT
 ---
 Part of the linkgit:git[1] suite
-- 
2.1.4

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

Microsoft

2015-02-09 Thread mugarik 
Ön nyert kilencszázezer dolláros Microsoft, küldje nevet, országot és a tel




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

[PATCH 0/8] Fix some problems with reflog expiration

2015-02-09 Thread Michael Haggerty 
In addition to a few cleanups, this patch series fixes some problems
that I noticed when working on mh/reflog-expire:

* Ignore '--updateref' when expiring the reflog of a symbolic
  reference, because the alternatives are all pretty silly. See the
  log message for commit 6/8 for more information.

* Ignore '--updateref' when *all* reflog entries are expired by git
  reflog expire or git reflog delete. Currently, this sets the
  reference to 0{40}, which breaks the repository. (Another
  alternative would be to delete the reference in this situation, but
  that seemed too radical to me somehow.)

* When expiring the reflog for a symbolic reference, lock the symbolic
  reference rather than its referent.

This patch series applies on top of master merged together with
sb/atomic-push, like the refs-have-new patch series that I just
submitted. It is also available from my GitHub account [1] as branch
expire-updateref-fixes.

There is a minor conflict between this patch series and
mh/refs-have-new:

 HEAD
if (!is_null_sha1(update-new_sha1)) {
if (!update-lock-force_write 
!hashcmp(update-lock-old_sha1, update-new_sha1)) 
{
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock, 
update-new_sha1,
  update-msg)) {
||| merged common ancestors
if (!is_null_sha1(update-new_sha1)) {
if (write_ref_sha1(update-lock, update-new_sha1,
   update-msg)) {
===
if ((flags  REF_HAVE_NEW)  !is_null_sha1(update-new_sha1)) {
if (write_ref_sha1(update-lock, update-new_sha1,
   update-msg)) {
 refs-have-new

It can be resolved in the obvious way:


if ((flags  REF_HAVE_NEW)  !is_null_sha1(update-new_sha1)) {
if (!update-lock-force_write 
!hashcmp(update-lock-old_sha1, update-new_sha1)) 
{
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock, 
update-new_sha1,
  update-msg)) {


By the way, both of these patch series conflict with
sb/atomic-push-fix, which is in pu. My understanding is that Stefan
wants to rework that patch series anyway, but if not I would be happy
to show how to resolve the conflicts.

Michael

[1] https://github.com/mhagger/git

Michael Haggerty (8):
  write_ref_sha1(): remove check for lock == NULL
  write_ref_sha1(): Move write elision test to callers
  lock_ref_sha1_basic(): do not set force_write for missing references
  reflog: fix documentation
  reflog: rearrange the manpage
  reflog_expire(): ignore --updateref for symbolic references
  reflog_expire(): never update a reference to null_sha1
  reflog_expire(): lock symbolic refs themselves, not their referent

 Documentation/git-reflog.txt | 65 +++-
 builtin/reflog.c |  2 +-
 refs.c   | 55 -
 3 files changed, 65 insertions(+), 57 deletions(-)

-- 
2.1.4

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

[PATCH 6/8] reflog_expire(): ignore --updateref for symbolic references

2015-02-09 Thread Michael Haggerty 
If we are expiring reflog entries for a symbolic reference, then how
should --updateref be handled if the newest reflog entry is expired?

Option 1: Update the referred-to reference. (This is what the current
code does.) This doesn't make sense, because the referred-to reference
has its own reflog, which hasn't been rewritten.

Option 2: Update the symbolic reference itself (as in, REF_NODEREF).
This would convert the symbolic reference into a non-symbolic
reference (e.g., detaching HEAD), which is surely not what a user
would expect.

Option 3: Error out. This is plausible, but it would make the
following usage impossible:

git reflog expire ... --updateref --all

Option 4: Ignore --updateref for symbolic references.

We choose to implement option 4.

Note: there are still other problems in this code that will be fixed
in a moment.

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
 Documentation/git-reflog.txt |  3 ++-
 refs.c   | 15 ---
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index f15a48e..9b87b46 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -85,7 +85,8 @@ them.
 
 --updateref::
Update the ref with the sha1 of the top reflog entry (i.e.
-   ref@\{0\}) after expiring or deleting.
+   ref@\{0\}) after expiring or deleting.  (This option is
+   ignored for symbolic references.)
 
 --rewrite::
While expiring or deleting, adjust each reflog entry to ensure
diff --git a/refs.c b/refs.c
index b083858..c0001da 100644
--- a/refs.c
+++ b/refs.c
@@ -4025,6 +4025,7 @@ int reflog_expire(const char *refname, const unsigned 
char *sha1,
struct ref_lock *lock;
char *log_file;
int status = 0;
+   int type;
 
memset(cb, 0, sizeof(cb));
cb.flags = flags;
@@ -4036,7 +4037,7 @@ int reflog_expire(const char *refname, const unsigned 
char *sha1,
 * reference itself, plus we might need to update the
 * reference if --updateref was specified:
 */
-   lock = lock_ref_sha1_basic(refname, sha1, NULL, 0, NULL);
+   lock = lock_ref_sha1_basic(refname, sha1, NULL, 0, type);
if (!lock)
return error(cannot lock ref '%s', refname);
if (!reflog_exists(refname)) {
@@ -4073,10 +4074,18 @@ int reflog_expire(const char *refname, const unsigned 
char *sha1,
(*cleanup_fn)(cb.policy_cb);
 
if (!(flags  EXPIRE_REFLOGS_DRY_RUN)) {
+   /*
+* It doesn't make sense to adjust a reference pointed
+* to by a symbolic ref based on expiring entries in
+* the symbolic reference's reflog.
+*/
+   int update = (flags  EXPIRE_REFLOGS_UPDATE_REF) 
+   ~(type  REF_ISSYMREF);
+
if (close_lock_file(reflog_lock)) {
status |= error(couldn't write %s: %s, log_file,
strerror(errno));
-   } else if ((flags  EXPIRE_REFLOGS_UPDATE_REF) 
+   } else if (update 
(write_in_full(lock-lock_fd,
sha1_to_hex(cb.last_kept_sha1), 40) != 40 ||
 write_str_in_full(lock-lock_fd, \n) != 1 ||
@@ -4087,7 +4096,7 @@ int reflog_expire(const char *refname, const unsigned 
char *sha1,
} else if (commit_lock_file(reflog_lock)) {
status |= error(unable to commit reflog '%s' (%s),
log_file, strerror(errno));
-   } else if ((flags  EXPIRE_REFLOGS_UPDATE_REF)  
commit_ref(lock)) {
+   } else if (update  commit_ref(lock)) {
status |= error(couldn't set %s, lock-ref_name);
}
}
-- 
2.1.4

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

[PATCH 1/8] write_ref_sha1(): remove check for lock == NULL

2015-02-09 Thread Michael Haggerty 
None of the callers pass NULL to this function, and there doesn't seem
to be any usefulness to allowing them to do so.

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
 refs.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/refs.c b/refs.c
index c5fa709..d1130e2 100644
--- a/refs.c
+++ b/refs.c
@@ -3080,10 +3080,6 @@ static int write_ref_sha1(struct ref_lock *lock,
static char term = '\n';
struct object *o;
 
-   if (!lock) {
-   errno = EINVAL;
-   return -1;
-   }
if (!lock-force_write  !hashcmp(lock-old_sha1, sha1)) {
unlock_ref(lock);
return 0;
-- 
2.1.4

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

[PATCH 8/8] reflog_expire(): lock symbolic refs themselves, not their referent

2015-02-09 Thread Michael Haggerty 
When processing the reflog of a symbolic ref, hold the lock on the
symbolic reference itself, not on the reference that it points to.

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
 refs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/refs.c b/refs.c
index 1b2a497..3fcf342 100644
--- a/refs.c
+++ b/refs.c
@@ -4037,7 +4037,7 @@ int reflog_expire(const char *refname, const unsigned 
char *sha1,
 * reference itself, plus we might need to update the
 * reference if --updateref was specified:
 */
-   lock = lock_ref_sha1_basic(refname, sha1, NULL, 0, type);
+   lock = lock_ref_sha1_basic(refname, sha1, NULL, REF_NODEREF, type);
if (!lock)
return error(cannot lock ref '%s', refname);
if (!reflog_exists(refname)) {
-- 
2.1.4

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

[PATCH 2/8] write_ref_sha1(): Move write elision test to callers

2015-02-09 Thread Michael Haggerty 
write_ref_sha1() previously skipped the write if the reference already
had the desired value, unless lock-force_write was set. Instead,
perform that test at the callers.

Two of the callers (in rename_ref()) unconditionally set force_write
just before calling write_ref_sha1(), so they don't need the extra
check at all. Nor do they need to set force_write anymore.

The last caller, in ref_transaction_commit(), still needs the test.

Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
 refs.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/refs.c b/refs.c
index d1130e2..651e37e 100644
--- a/refs.c
+++ b/refs.c
@@ -2878,7 +2878,6 @@ int rename_ref(const char *oldrefname, const char 
*newrefname, const char *logms
error(unable to lock %s for update, newrefname);
goto rollback;
}
-   lock-force_write = 1;
hashcpy(lock-old_sha1, orig_sha1);
if (write_ref_sha1(lock, orig_sha1, logmsg)) {
error(unable to write current sha1 into %s, newrefname);
@@ -2894,7 +2893,6 @@ int rename_ref(const char *oldrefname, const char 
*newrefname, const char *logms
goto rollbacklog;
}
 
-   lock-force_write = 1;
flag = log_all_ref_updates;
log_all_ref_updates = 0;
if (write_ref_sha1(lock, orig_sha1, NULL))
@@ -3080,10 +3078,6 @@ static int write_ref_sha1(struct ref_lock *lock,
static char term = '\n';
struct object *o;
 
-   if (!lock-force_write  !hashcmp(lock-old_sha1, sha1)) {
-   unlock_ref(lock);
-   return 0;
-   }
o = parse_object(sha1);
if (!o) {
error(Trying to write ref %s with nonexistent object %s,
@@ -3797,15 +3791,21 @@ int ref_transaction_commit(struct ref_transaction 
*transaction,
struct ref_update *update = updates[i];
 
if (!is_null_sha1(update-new_sha1)) {
-   if (write_ref_sha1(update-lock, update-new_sha1,
-  update-msg)) {
+   if (!update-lock-force_write 
+   !hashcmp(update-lock-old_sha1, update-new_sha1)) 
{
+   unlock_ref(update-lock);
+   update-lock = NULL;
+   } else if (write_ref_sha1(update-lock, 
update-new_sha1,
+ update-msg)) {
update-lock = NULL; /* freed by write_ref_sha1 
*/
strbuf_addf(err, Cannot update the ref '%s'.,
update-refname);
ret = TRANSACTION_GENERIC_ERROR;
goto cleanup;
+   } else {
+   /* freed by write_ref_sha1(): */
+   update-lock = NULL;
}
-   update-lock = NULL; /* freed by write_ref_sha1 */
}
}
 
-- 
2.1.4

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

Re: [PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees

2015-02-09 Thread Duy Nguyen 
On Mon, Feb 9, 2015 at 12:36 AM, Jens Lehmann jens.lehm...@web.de wrote:
 I wonder if it's worth all the hassle to invent new names. Wouldn't
 it be much better to just keep a list of per-worktree configuration
 value names and use that inside the config code to decide where to
 find them for multiple work trees. That would also work easily for
 stuff like EOL-config and would push the complexity in the config
 machinery and not onto the user.

It's certainly possible to relocate core.worktree to outside
$GIT_DIR/config. But I don't think it helps. If anything it'll make it
harder to distinguish the old setup and the new one. I think we need a
clear signal that will make old git barf on new setup, to be safe.
Maybe stepping core.repositoryformatversion, or breaking .git file
format when we switch to the new setup (with $GIT_COMMON_DIR).

Or.. perhaps we could use the old setup for primary worktree and the
new one for secondary worktrees of the same submodule. In these
secondary submodules, $GIT_COMMON_DIR is enough to make old git reject
them. And we could just reuse core.worktree, if we can make
core.worktree in $GIT_DIR/config.worktree shadow one in
$GIT_DIR/config..

Need to study git-submodule.sh some more..
-- 
Duy
--
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

Как договаривались

2015-02-09 Thread Виолетта 
Hello

По Вашему желанию направляю наше предложение


praic-list.doc
Description: MS-Word document

Re: [PATCH 2/2] sha1_file: fix iterating loose alternate objects

2015-02-09 Thread Kyle J. McKay 

On Feb 8, 2015, at 17:15, Jeff King wrote:
[...]

Signed-off-by: Jonathon Mah m...@jonathonmah.com
Helped-by: Kyle J. McKay mack...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
I think the S-O-B should still stand, as the code is now a mix of our
work, and the tests are still Jonathon's. But let me know if you do  
not

want your name attached to this. ;)


That's fine.

This fix looks much better. :)

Unfortunately I can no longer reproduce the original bug as the  
repository that caused it is no longer in a state that triggers the  
problem (and my backups of it are either slightly too old or slightly  
too new).


-Kyle

--
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: EOL handling (EGit/svn/Windows)

2015-02-09 Thread Torsten Bögershausen 

On 02/09/2015 11:22 PM, Piotr Krukowiecki wrote:
Any other suggestions?

My, somewhat personally, suggestion:
If there is more than one developer, don't use core.autocrlf at all-
it is a local setting, which doesn't travel through the repo, and
is slightly different in Git Egit, depending on the version.

Git for Windows has it enabled by default, Cygwin has not.

Which Git versions are you using ?
How many people are there involved, how many on Windows, how many on Linux ?
Do you want to commit to svn, or is this a one-time conversion ?

If it is a one-time conversion, and you continue to work in Git only,
then the cleanest, most portable and future proof way is to use the 
.gitattributes file,

add that to the repo, do the normalization  and push.
A line like this:
* text=auto
is the easiest way.

Have a look at
https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
take a tee or coffee, do some experiments first with a dummy repo,
but all the client OS/Gits involved.
Please let us know the result (or feel free to ask more questions)


--
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: low memory system to clone larger repo

2015-02-09 Thread matthew sporleder 
Below is the output from my index-pack/clone over git://

This is with the recent memory patch applied but testing some less crazy tuning.
--

The corruption of the signal number shows up in google from other
people so I guess it's a lingering bug.

*
git-tests $ git clone git://github.com/jsonn/src
Cloning into 'src'...
remote: Counting objects: 3497569, done.
remote: Compressing objects: 100% (640647/640647), done.
error: index-pack died of signal 9497569), 990.62 MiB | 8.35 MiB/s
fatal: index-pack failed






On Mon, Feb 9, 2015 at 6:32 AM, Duy Nguyen pclo...@gmail.com wrote:
 On Thu, Jan 8, 2015 at 11:10 PM, matthew sporleder msporle...@gmail.com 
 wrote:
 I am attempting to clone this repo: https://github.com/jsonn/src/

 This repo has 3.4M objects. Basic book keeping would cost 200MB (in
 practice it'll be higher because I'm assuming no deltas in my
 calculation). On my 64-bit system, it already uses 400+ MB at the
 beginning of delta resolving phase, and is about 500MB during. 32-bit
 systems cost less but I doubt we could keep it within 256 MB limit. I
 think you just need more powerful machines for a repo this size.

 Also, they have some large files (udivmodti4_test.c 16MB, MD5SUMS
 6MB..) These giant files could make index-pack use more memory
 especially if they are deltified. If you repack the repo with
 core.bigFileThreshold about 1-2MB, then clone, you may get a better
 memory consumption, but at the cost of bigger packs.
 --
 Duy
--
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 05/11] ref_transaction_delete(): remove have_old parameter

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 Instead, if old_sha1 is non-NULL, verify it; otherwise, don't.

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu

Reviewed-by: Stefan Beller sbel...@google.com apart from the commit message.
--
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 08/11] ref_transaction_create(): check that new_sha1 is valid

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 Creating a reference requires a new_sha1 that is not NULL and not
 null_sha1.

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu

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

Re: git 2.2.2 annotate crash (strbuf.c:32)

2015-02-09 Thread Eric Sunshine 
On Mon, Feb 09, 2015 at 11:33:39AM +0100, Dilyan Palauzov wrote:
 the point is that with exactly the same configuration on one
 computer there is crash and on another one things work just fine.
 
 I found out that line builtin/blame.c:1675 makes the problems:
 
 if (len) {
   printf(blame.c:1676, subject: %s, len: %i\n, subject, len);
 --  strbuf_add(ret-summary, subject, len);  --
 } else
strbuf_addf(ret-summary, (%s), sha1_to_hex(commit-object.sha1));
 
 commenting it out and compiling does not lead to crashing git
 anymore. You can find below the output of printf.
 
 git clone git://git.cyrusimap.org/cyrus-imapd
 git annotate timsieved/parser.c
 
 *** Error in `git': double free or corruption (!prev):
 0x022e4b40 ***

There is a bit of suspicious code in builtin/blame.c where it is
destroying the commit_info without ever initializing it, and this
happens many times when blaming 'timsieved/parser.c'. Does the
following patch fix the problem for you?

--- 8 ---
diff --git a/builtin/blame.c b/builtin/blame.c
index 303e217..a3cc972 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2085,7 +2085,6 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
 
for (e = sb-ent; e; e = e-next) {
struct origin *suspect = e-suspect;
-   struct commit_info ci;
int num;
 
if (compute_auto_abbrev)
@@ -2096,6 +2095,7 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
if (longest_file  num)
longest_file = num;
if (!(suspect-commit-object.flags  METAINFO_SHOWN)) {
+   struct commit_info ci;
suspect-commit-object.flags |= METAINFO_SHOWN;
get_commit_info(suspect-commit, ci, 1);
if (*option  OUTPUT_SHOW_EMAIL)
@@ -2104,6 +2104,7 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
num = utf8_strwidth(ci.author.buf);
if (longest_author  num)
longest_author = num;
+   commit_info_destroy(ci);
}
num = e-s_lno + e-num_lines;
if (longest_src_lines  num)
@@ -2113,8 +2114,6 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
longest_dst_lines = num;
if (largest_score  ent_score(sb, e))
largest_score = ent_score(sb, e);
-
-   commit_info_destroy(ci);
}
max_orig_digits = decimal_width(longest_src_lines);
max_digits = decimal_width(longest_dst_lines);
-- 
2.3.0.rc2.191.g303d43c
--- 8 ---
--
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] sha1_file.c: make sure open_sha1_file does not open a directory

2015-02-09 Thread Junio C Hamano 
Jeff King p...@peff.net writes:

 However, the first thing for_each_loose_file_in_objdir is going to do is
 stick the path into a strbuf. So perhaps the most sensible thing is to
 just teach it to take a strbuf from the caller. I'll work up a patch.

 It looks like a1b47246 isn't even in next yet, so I'll build it
 directly on what is already in master, dropping Jonathan's patch.

Thanks; looks very sensible.
--
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 2.2.2 annotate crash (strbuf.c:32)

2015-02-09 Thread Dilyan Palauzov 

Hello,

this patch fixes the problem for me.

Thanks
  Dilyan

On 09.02.2015 19:46, Eric Sunshine wrote:

On Mon, Feb 09, 2015 at 11:33:39AM +0100, Dilyan Palauzov wrote:

the point is that with exactly the same configuration on one
computer there is crash and on another one things work just fine.

I found out that line builtin/blame.c:1675 makes the problems:

if (len) {
   printf(blame.c:1676, subject: %s, len: %i\n, subject, len);
--  strbuf_add(ret-summary, subject, len);  --
} else
strbuf_addf(ret-summary, (%s), sha1_to_hex(commit-object.sha1));

commenting it out and compiling does not lead to crashing git
anymore. You can find below the output of printf.

git clone git://git.cyrusimap.org/cyrus-imapd
git annotate timsieved/parser.c

*** Error in `git': double free or corruption (!prev):
0x022e4b40 ***


There is a bit of suspicious code in builtin/blame.c where it is
destroying the commit_info without ever initializing it, and this
happens many times when blaming 'timsieved/parser.c'. Does the
following patch fix the problem for you?

--- 8 ---
diff --git a/builtin/blame.c b/builtin/blame.c
index 303e217..a3cc972 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2085,7 +2085,6 @@ static void find_alignment(struct scoreboard *sb, int 
*option)

for (e = sb-ent; e; e = e-next) {
struct origin *suspect = e-suspect;
-   struct commit_info ci;
int num;

if (compute_auto_abbrev)
@@ -2096,6 +2095,7 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
if (longest_file  num)
longest_file = num;
if (!(suspect-commit-object.flags  METAINFO_SHOWN)) {
+   struct commit_info ci;
suspect-commit-object.flags |= METAINFO_SHOWN;
get_commit_info(suspect-commit, ci, 1);
if (*option  OUTPUT_SHOW_EMAIL)
@@ -2104,6 +2104,7 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
num = utf8_strwidth(ci.author.buf);
if (longest_author  num)
longest_author = num;
+   commit_info_destroy(ci);
}
num = e-s_lno + e-num_lines;
if (longest_src_lines  num)
@@ -2113,8 +2114,6 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
longest_dst_lines = num;
if (largest_score  ent_score(sb, e))
largest_score = ent_score(sb, e);
-
-   commit_info_destroy(ci);
}
max_orig_digits = decimal_width(longest_src_lines);
max_digits = decimal_width(longest_dst_lines);


--
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] Geolocation support

2015-02-09 Thread Junio C Hamano 
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:

 On Mon, Feb 9, 2015 at 2:24 AM, Junio C Hamano gits...@pobox.com wrote:
 In case I was not clear, I do not think it is likely for us to accept
 a patch that mucks with object header fields with this information.
 Have them in the log text and let UI interpret them.

 We've already told clients for a long time to ignore fields they don't
 know about, 

Yes, but the reason that mechanism is there is not because we want
to add random cruft Git does not have to know about.  It is to avoid
older Git from suddenly stop working when we really need to add new
essential things.

This was discussed in great length on this list already.

cf. http://thread.gmane.org/gmane.comp.version-control.git/138848/focus=138852

More importantly, adding non-essential stuff left and right will
force third party Git reimplementations to pay attention to them and
also will leave room for them to make mistakes when deciding what to
propagate, what to drop and what to update when rewriting commits
via rebase, cherry-pick, etc.

 why would we not store what's intended to be
 machine-readable key-value pair data in the commit object itself,

I think this sentence gets it backwards.  The question to ask is if
it is an arbitrary cruft that the end users are better off if they
can easily typofix in the commit message log editor, or is it
essential for Git to operate correctly and end users shouldn't be
allowed to muck with in the editor?

 The expected location format is CITY, COUNTRY (LAT, LON).

I would expect that I can typofix Les Angeles to Los Angeles,
if I were using this feature.
--
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

Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Paul E. McKenney 
Hello!

I need to be able to put the following Cc in a git commit:

Cc: sta...@vger.kernel.org

Yet I cannot allow git-send-email to actually send email to that address,
lest I get an automated nastygram in response.  I found the --to-cmd=
option to git-send-email, but it looks to only add email addresses, never
delete them.  I also found the --suppress-cc= option to git-send-email,
but it appears to suppress all Cc emails, not just selected ones.

One approach that occurred to me is to hand-edit the files produced
by git-format-patch, removing sta...@vger.kernel.org entirely prior to
using git-send-email.  However, this is a bit error-prone.  Yes, I could
script it, but with my luck, I will eventually end up having my script
mangle some patch, for example to the Linux kernel's MAINTAINERS file.
Furthermore, this approach means that people reviewing the patches
cannot see the Cc stable entries (though I could presumably comment them
out somehow).

Another approach is to add the stable Ccs just before doing the pull
request, by my upstream maintainer is not fond of that approach.  Nor am
I, as it would be all to easy to forget to add the stable Ccs.  Or to
get them wrong.

I can't be the only person wanting to do something like this.  So is
there some git option that I am missing here?

Thanx, Paul

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

Re: [PATCH 09/11] ref_transaction_delete(): check that old_sha1 is not null_sha1

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 It makes no sense to delete a reference that is already known not to
 exist.

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu

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

Re: [PATCH 11/11] update_ref(): improve documentation

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 Add a docstring for update_ref(), emphasizing its similarity to
 ref_transaction_update(). Rename its parameters to match those of
 ref_transaction_update().

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu

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

Re: [PATCH 01/11] refs: move REF_DELETING to refs.c

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 It is only used internally now. Document it a little bit better, too.

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/11] commit: add tests of commit races

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:

 diff --git a/t/t7516-commit-races.sh b/t/t7516-commit-races.sh
 new file mode 100755
 index 000..5efa351
 --- /dev/null
 +++ b/t/t7516-commit-races.sh
 @@ -0,0 +1,38 @@
 +#!/bin/sh
 +#
 +# Copyright (c) 2014 Michael Haggerty mhag...@alum.mit.edu

What is the projects stance on copyright lines?
I've seen files (most of them from the beginning) having some copyright lines,
other files (often introduced way later) not having them, because
we're git and have
history, so we know who did it.

The tests themselves look fine.

Is there a reason you did not append the tests in 7509 ?



--
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 07/11] commit: avoid race when creating orphan commits

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 If, during the initial check, HEAD doesn't point at anything, then we

Maybe
If HEAD doesn't point at anything during the initial check, then... ?
(Being a non native speaker is hard. These commas look so confusing,
so the version without commas makes it way easier to read for me.)

Otherwise
Reviewed-by: Stefan Beller sbel...@google.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Fix some problems with reflog expiration

2015-02-09 Thread Stefan Beller 
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:

 By the way, both of these patch series conflict with
 sb/atomic-push-fix, which is in pu. My understanding is that Stefan
 wants to rework that patch series anyway, but if not I would be happy
 to show how to resolve the conflicts.

Heh, I had it already reworked on Friday evening, but forgot to send it out
for review. As mentioned before, sb/atomic-push-fix is a misleading branch name
as it actually enables large transactions [ large means  $(ulimit -n) ].

I don't mind reworking that series again on top of either this or the other
patch series you sent out, as I wasn't entirely happy with it anyway.
(Naming is hard)
--
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/11] refs: remove the gap in the REF_* constant values

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 There is no reason to reserve a gap between the public and private
 flags values.

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
 ---
  refs.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/refs.c b/refs.c
 index cd5208b..477a5b3 100644
 --- a/refs.c
 +++ b/refs.c
 @@ -44,7 +44,8 @@ static unsigned char refname_disposition[256] = {
   * Used as a flag to ref_transaction_delete when a loose ref is being
   * pruned.
   */
 -#define REF_ISPRUNING  0x0100
 +#define REF_ISPRUNING  0x04
 +

I'm ok with that change, though I remember Duy had once started to
create a table in a header file documenting all positions of flags
(e.g foo.c would use 1{1,2,3,7}, and bar.c had 1{1,2,5,26} in
use).
I wonder if we should start a discussion on that topic. I think it
makes sense to have a central place documenting all the flags
(specially their bit allocation), but this one is only in one c file,
so we're really unlikely to
break something by having different defines pointing at the same bit.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] trailer: add a trailer.trimEmpty config option

2015-02-09 Thread Junio C Hamano 
Christian Couder christian.cou...@gmail.com writes:

 It is not designed like this because you only asked me to design it
 like this after the facts, when there was another email thread about
 conflicts blocks and one function you created could be used by the
 trailer code too.

 If you had asked this from the beginning I would certainly have done...

Because the process here is not somebody outlines the design and
gives it to laborer to implement, after the fact and from the
beginning are complaining to and asking for impossible.  You design
and implement and then it gets reviewed, not the other way around.

--
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 00/11] Allow reference values to be checked in a transaction

2015-02-09 Thread Junio C Hamano 
Michael Haggerty mhag...@alum.mit.edu writes:

 The main purpose of this series is to simplify the interface to
 reference transactions as follows:

 * Remove the need to supply an explicit have_old parameter to
   ref_transaction_update() and ref_transaction_delete(). Instead,
   check the old_sha1 if and only if it is non-NULL.

 * Allow NULL to be supplied to ref_transaction_update() as new_sha1,
   in which case old_sha1 will be verified under lock, but the
   reference's value will not be altered.

 * Add a function ref_transaction_verify(), which verifies the current
   value of a reference without changing it.

 * Make the similarity between ref_transaction_update() and
   update_ref() more obvious.

 Along the way, it fixes a race that could happen if two processes try
 to create an orphan commit at the same time.

 This patch series applies on top of master merged together with
 sb/atomic-push, which in turn depends on mh/reflog-expire.

I am a bit puzzled by your intentions, so help me out.

I see that your understanding is that Stefan will be rerolling the
push atomicity thing; wouldn't we then want to have a fix and
clean topic like this one first and build the push atomicity thing
on top instead?

In other words, would it make sense to extend mh/reflog-expire (in
'next') topic with commits from Fix some problems with reflog
expiration (8 patches) series and this series to fix and clean it?

We may even want to rebase/reroll mh/reflog-expire on top of v2.3
while doing so to adjust to the transaction stuff, if that makes
some of the changes in the two new series unnecessary (if these fix
and clean up changes made in mh/reflog-expire in 'next', that 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 10/11] ref_transaction_verify(): new function to check a reference's value

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
  /*
 - * Add a reference update to transaction.  new_sha1 is the value that
 - * the reference should have after the update, or null_sha1 if it should
 - * be deleted.  If old_sha1 is non-NULL, then it the value
 - * that the reference should have had before the update, or null_sha1 if
 - * it must not have existed beforehand.
 - * Function returns 0 on success and non-zero on failure. A failure to update
 - * means that the transaction as a whole has failed and will need to be
 - * rolled back.
 + * Add a reference update to transaction. new_sha1 is the value that
 + * the reference should have after the update, or null_sha1 if it
 + * should be deleted. If new_sha1 is NULL, then the reference is not
 + * changed at all. old_sha1 is the value that the reference must have
 + * before the update, or null_sha1 if it must not have existed
 + * beforehand. The old value is checked after the lock is taken to
 + * prevent races. If the old value doesn't agree with old_sha1, the
 + * whole transaction fails. If old_sha1 is NULL, then the previous
 + * value is not checked.
 + *
 + * Return 0 on success and non-zero on failure. Any failure in the
 + * transaction means that the transaction as a whole has failed and
 + * will need to be rolled back.

Do we need to be explicit about having to rollback everything in each
ref_transaction_* function documentation?

I like the new wording (first paragraph) of this function documentation.
--
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 04/11] ref_transaction_update(): remove have_old parameter

2015-02-09 Thread Stefan Beller 
On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 Instead, if old_sha1 is non-NULL, verify it; otherwise, don't.

parsing error on that commit message. I needed to read the code to understand
what you want to say here.
The code itself is

Reviewed-by: Stefan Beller sbel...@google.com


 ref_transaction_delete() will get the same treatment in a moment.

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
 ---
  branch.c   |  5 +++--
  builtin/commit.c   |  2 +-
  builtin/fetch.c|  6 --
  builtin/receive-pack.c |  2 +-
  builtin/replace.c  |  2 +-
  builtin/tag.c  |  2 +-
  builtin/update-ref.c   |  7 ---
  fast-import.c  |  6 +++---
  refs.c | 18 --
  refs.h |  6 +++---
  sequencer.c|  2 +-
  walker.c   |  2 +-
  12 files changed, 31 insertions(+), 29 deletions(-)

 diff --git a/branch.c b/branch.c
 index 4bab55a..b002435 100644
 --- a/branch.c
 +++ b/branch.c
 @@ -284,8 +284,9 @@ void create_branch(const char *head,

 transaction = ref_transaction_begin(err);
 if (!transaction ||
 -   ref_transaction_update(transaction, ref.buf, sha1,
 -  null_sha1, 0, !forcing, msg, err) 
 ||
 +   ref_transaction_update(transaction, ref.buf,
 +  sha1, forcing ? NULL : null_sha1,
 +  0, msg, err) ||
 ref_transaction_commit(transaction, err))
 die(%s, err.buf);
 ref_transaction_free(transaction);
 diff --git a/builtin/commit.c b/builtin/commit.c
 index 7d90c35..5654abd 100644
 --- a/builtin/commit.c
 +++ b/builtin/commit.c
 @@ -1773,7 +1773,7 @@ int cmd_commit(int argc, const char **argv, const char 
 *prefix)
 ref_transaction_update(transaction, HEAD, sha1,
current_head
? current_head-object.sha1 : NULL,
 -  0, !!current_head, sb.buf, err) ||
 +  0, sb.buf, err) ||
 ref_transaction_commit(transaction, err)) {
 rollback_index_files();
 die(%s, err.buf);
 diff --git a/builtin/fetch.c b/builtin/fetch.c
 index 7b84d35..719bf4f 100644
 --- a/builtin/fetch.c
 +++ b/builtin/fetch.c
 @@ -416,8 +416,10 @@ static int s_update_ref(const char *action,

 transaction = ref_transaction_begin(err);
 if (!transaction ||
 -   ref_transaction_update(transaction, ref-name, ref-new_sha1,
 -  ref-old_sha1, 0, check_old, msg, err))
 +   ref_transaction_update(transaction, ref-name,
 +  ref-new_sha1,
 +  check_old ? ref-old_sha1 : NULL,
 +  0, msg, err))
 goto fail;

 ret = ref_transaction_commit(transaction, err);
 diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
 index 4e85e25..71be82e 100644
 --- a/builtin/receive-pack.c
 +++ b/builtin/receive-pack.c
 @@ -951,7 +951,7 @@ static const char *update(struct command *cmd, struct 
 shallow_info *si)
 if (ref_transaction_update(transaction,
namespaced_name,
new_sha1, old_sha1,
 -  0, 1, push,
 +  0, push,
err)) {
 rp_error(%s, err.buf);
 strbuf_release(err);
 diff --git a/builtin/replace.c b/builtin/replace.c
 index 85d39b5..54bf01a 100644
 --- a/builtin/replace.c
 +++ b/builtin/replace.c
 @@ -172,7 +172,7 @@ static int replace_object_sha1(const char *object_ref,
 transaction = ref_transaction_begin(err);
 if (!transaction ||
 ref_transaction_update(transaction, ref, repl, prev,
 -  0, 1, NULL, err) ||
 +  0, NULL, err) ||
 ref_transaction_commit(transaction, err))
 die(%s, err.buf);

 diff --git a/builtin/tag.c b/builtin/tag.c
 index e633f4e..232c28c 100644
 --- a/builtin/tag.c
 +++ b/builtin/tag.c
 @@ -733,7 +733,7 @@ int cmd_tag(int argc, const char **argv, const char 
 *prefix)
 transaction = ref_transaction_begin(err);
 if (!transaction ||
 ref_transaction_update(transaction, ref.buf, object, prev,
 -  0, 1, NULL, err) ||
 +  0, NULL, err) ||
 ref_transaction_commit(transaction, err))
 die(%s, err.buf);
 ref_transaction_free(transaction);
 diff --git a/builtin/update-ref.c b/builtin/update-ref.c
 index

Re: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Paul E. McKenney 
On Tue, Feb 10, 2015 at 08:03:19AM +0800, Greg KH wrote:
 On Mon, Feb 09, 2015 at 03:35:37PM -0800, Paul E. McKenney wrote:
  On Mon, Feb 09, 2015 at 01:53:50PM -0800, Jonathan Nieder wrote:
   Hi,
   
   Paul E. McKenney wrote:
   
Cc: sta...@vger.kernel.org
   
Yet I cannot allow git-send-email to actually send email to that 
address,
lest I get an automated nastygram in response.
   
   Interesting.  Last time this came up, the result seemed to be
   different[*].
  
  Hmmm...  Greg KH didn't say there were no automated nastygrams, just
  that he wasn't worried about it.
  
  I can try it on the next to-be-backported commit and see what happens.
 
 There are no automated nastygrams, it's a hit this key to send out
 this form message I have in my email client.
 
 The only time it triggers a false-positive is when I haven't had enough
 coffee in the morning, which is what happened recently with a patch from
 John Stultz.  If I've sent you that message incorrectly, I'm sorry,
 please let me know.

If that happened, it would have been a while back.

 Again, any patch cc:ed to stable that has a stable mark on it in the
 signed-off-by area is fine, and it helps me to know to watch out for
 things when they hit Linus's tree, or most importantly, to notice if
 they somehow _don't_ hit his tree.  Again, some recent patches from John
 fall in to that category, they didn't make it into Linus's tree when
 they probably should have for 3.19, and now I need to scoop them up
 quickly when they finally do.  If I hadn't been cc:ed on them, I would
 not have noticed that.
 
 Hope this helps explain things,

Yep, thank you!  I will add the Cc stable lines as appropriate and stop
bothering the git guys.  ;-)

Thanx, Paul

--
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] fast-import: avoid running end_packfile recursively

2015-02-09 Thread Jeff King 
When an import has finished, we run end_packfile() to
finalize the data and move the packfile into place. If this
process fails, we call die() and end up in our die_nicely()
handler.  Which unfortunately includes running end_packfile
to save any progress we made. We enter the function again,
and start operating on the pack_data struct while it is in
an inconsistent state, leading to a segfault.

One way to trigger this is to simply start two identical
fast-imports at the same time. They will both create the
same packfiles, which will then try to create identically
named .keep files. One will win the race, and the other
will die(), and end up with the segfault.

Since 3c078b9, we already reset the pack_data pointer to
NULL at the end of end_packfile. That covers the case of us
calling die() right after end_packfile, before we have
reinitialized the pack_data pointer. This new problem is
quite similar, except that we are worried about calling
die() _during_ end_packfile, not right after. Ideally we
would simply set pack_data to NULL as soon as we enter the
function, and operate on a copy of the pointer.

Unfortunately, it is not so easy. pack_data is a global, and
end_packfile calls into other functions which operate on the
global directly. We would have to teach each of these to
take an argument, and there is no guarantee that we would
catch all of the spots.

Instead, we can simply use a static flag to avoid
recursively entering the function. This is a little less
elegant, but it's short and fool-proof.

Signed-off-by: Jeff King p...@peff.net
---
 fast-import.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fast-import.c b/fast-import.c
index d0bd285..aac2c24 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -947,9 +947,12 @@ static void unkeep_all_packs(void)
 
 static void end_packfile(void)
 {
-   if (!pack_data)
+   static int running;
+
+   if (running || !pack_data)
return;
 
+   running = 1;
clear_delta_base_cache();
if (object_count) {
struct packed_git *new_p;
@@ -999,6 +1002,7 @@ static void end_packfile(void)
}
free(pack_data);
pack_data = NULL;
+   running = 0;
 
/* We can't carry a delta across packfiles. */
strbuf_release(last_blob.data);
-- 
2.3.0.rc1.287.g761fd19
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] contrib/completion: suppress stderror in bash

2015-02-09 Thread SZEDER Gábor 


Hi,


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


Matt Korostoff mkorost...@gmail.com writes:



diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 2fece98..72251cc 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -412,7 +412,7 @@ __git_refs_remotes ()
 __git_remotes ()
 {
local i IFS=$'\n' d=$(__gitdir)
-   test -d $d/remotes  ls -1 $d/remotes
+   test -d $d/remotes  ls -1 $d/remotes 2/dev/null
for i in $(git --git-dir=$d config --get-regexp
'remote\..*\.url' 2/dev/null); do
i=${i#remote.}
echo ${i/.url*/}


Do I smell some bitrotting here?

This function just lists all the defined remotes, first by listing the  
directories under refs/remotes to get the legacy remotes and then  
loops over 'git config's output to get the modern ones.  This  
predates the arrival of the 'git remote' command in January 2007, so  
it was really a long time ago.


We should just run 'git remote' instead, shouldn't we?


Cheers,
Gábor
--
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 00/11] Allow reference values to be checked in a transaction

2015-02-09 Thread Stefan Beller 
On Mon, Feb 9, 2015 at 12:40 PM, Michael Haggerty mhag...@alum.mit.edu wrote:


 I am not sure what advantages this would bring. A better history
 for bisection? I cannot speak for Michael, but my understanding was
 to have mh/reflog-expire and sb/atomic-push-fix merged now that 2.3
 is out and everything else on top is unclear/rerolled/discussed as needed.

 Stefan, I think you mean sb/atomic-push, not sb/atomic-push-fix, right?

Of course, sorry for adding more confusion here.
--
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

Gmail Message rejection

2015-02-09 Thread erik 
Can I submit this as a bug report, that sending something from the  
gmail client results in this response?


Delivery to the following recipient failed permanently:

 git@vger.kernel.org

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the  
server for the recipient domain vger.kernel.org by vger.kernel.org.  
[209.132.180.67].


The error that the other server returned was:
550 5.7.1 Content-Policy reject msg: The message contains HTML  
subpart, therefore we consider it SPAM or Outlook Virus.  TEXT/PLAIN  
is accepted.! BF:H 0.338318; S932497AbbBIUIh


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

Windows Bluescreen

2015-02-09 Thread erik 


I find that preview 1.8 is bluescreening on about 1 of 3 ssh pushes.   
1.9 preview 12-17-2014 doesn't even bluescreen, the windows gui locks  
until reset.


Sample command:
git push omv master\r

config. =

[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
hideDotFiles = dotGitOnly
[remote omv]
url = gitpush@192.168.0.100:/git-repos/HexEncrypter
fetch = +refs/heads/*:refs/remotes/omv/*

--
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 00/11] Allow reference values to be checked in a transaction

2015-02-09 Thread Junio C Hamano 
Michael Haggerty mhag...@alum.mit.edu writes:

 On 02/09/2015 08:05 PM, Stefan Beller wrote:
 On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote:
 Michael Haggerty mhag...@alum.mit.edu writes:
 [...]
 This patch series applies on top of master merged together with
 sb/atomic-push, which in turn depends on mh/reflog-expire.

 I am a bit puzzled by your intentions, so help me out.

 I see that your understanding is that Stefan will be rerolling the
 push atomicity thing; wouldn't we then want to have a fix and
 clean topic like this one first and build the push atomicity thing
 on top instead?
 
 My understanding is to not reroll origin/sb/atomic-push, but
 origin/sb/atomic-push-fix (which is worded misleading. It is not about
 atomic pushes, but about enabling large transactions in my understanding)

 Yes, that is what I thought.
 ...
 Both series have to do with reflogs, but they are logically pretty
 independent. In particular, Fix some problems with reflog expiration
 fixes problems that existed before mh/reflog-expire. And considering
 that one topic is quite mature whereas the the other is just making its
 debut, it seemed like yoking them together would slow down the first
 topic for no good reason.
 ...
 I expected that mh/reflog-expire and sb/atomic-push would be merged
 pretty early in the 2.4 cycle (they are both in next already). Junio, is
 that not your plan?

OK, I am glad I asked for clarifications.  It was that I felt uneasy
to see many new this cleans and fixes while there are in-flight
topics in the same area.

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

Re: [PATCH 7/8] reflog_expire(): never update a reference to null_sha1

2015-02-09 Thread Eric Sunshine 
On Mon, Feb 9, 2015 at 4:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 Currently, if --updateref is specified and the very last reflog entry
 is expired or deleted, the reference's value is set to 0{40}. This is
 an invalid state of the repository, and breaks, for example, git
 fsck and git for-each-ref.

 The only place we use --updateref in our own code is when dropping
 stash entries. In that code, the very next step is to check if the
 reflog has been made empty, and if so, delete the refs/stash
 reference entirely. Thus that code path ultimately leaves the
 repository in a valid state.

 But we don't want the repository in an invalid state even temporarily,
 and we don't want leave an invalid state if other callers of git

s/want/want to/

 reflog expire|delete --updateref don't think to do the extra cleanup
 step.

 So, if git reflog expire|delete leaves no more entries in the
 reflog, just leave the reference un-updated.

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
--
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: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Junio C Hamano 
Paul E. McKenney paul...@linux.vnet.ibm.com writes:

 I need to be able to put the following Cc in a git commit:

 Cc: sta...@vger.kernel.org

 Yet I cannot allow git-send-email to actually send email to that address,
 lest I get an automated nastygram in response.  I found the --to-cmd=
 option to git-send-email, but it looks to only add email addresses, never
 delete them.  I also found the --suppress-cc= option to git-send-email,
 but it appears to suppress all Cc emails, not just selected ones.

 One approach that occurred to me is to hand-edit the files produced
 by git-format-patch, removing sta...@vger.kernel.org entirely prior to
 using git-send-email.  However, this is a bit error-prone.  Yes, I could
 script it, but with my luck, I will eventually end up having my script
 mangle some patch, for example to the Linux kernel's MAINTAINERS file.
 Furthermore, this approach means that people reviewing the patches
 cannot see the Cc stable entries (though I could presumably comment them
 out somehow).

 Another approach is to add the stable Ccs just before doing the pull
 request, by my upstream maintainer is not fond of that approach.  Nor am
 I, as it would be all to easy to forget to add the stable Ccs.  Or to
 get them wrong.

 I can't be the only person wanting to do something like this.  So is
 there some git option that I am missing here?

No, I do not think we have a way to blacklist certain recipient
addresses from getting passed to the MTA, and I do not object to
addition of such a mechanism if there is a valid need to do so.

It feels a bit too convoluted to say Cc: to this address in the
log message and then nonono, I do not want to send there, though.
Why do you want to have Cc: in the log message if you do not want to
send e-mail to that address in the first place?  Allowing the
behaviour you are asking for would mean that those who see that the
commit appeared on a branch would not be able to assume that the
patch has already been sent to the stable review address, 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] contrib/completion: suppress stderror in bash completion of git remotes

2015-02-09 Thread Matt Korostoff 
Here are some screen shots demonstrating the issue I'm describing here:

before this patch:
https://cloud.githubusercontent.com/assets/1197335/6108333/1f3b10fa-b040-11e4-9164-3c7769dae110.gif

after this patch:
https://cloud.githubusercontent.com/assets/1197335/6108340/3878cad0-b040-11e4-9994-dcd5c4d62bba.gif

On Mon, Feb 9, 2015 at 3:58 PM, Matt Korostoff mkorost...@gmail.com wrote:
 In some system configurations there is a bug with the
 __git_remotes function.  Specifically, there is a problem
 with line 415, `test -d $d/remotes  ls -1 $d/remotes`.
 While `test -d` is meant to prevent listing the remotes
 directory if it does not exist, in some system, `ls` will
 run regardless.

 This results in an error in which typing `git push or` + `tab`
 prints out `ls: .git/remotes: No such file or directory`.
 This can be fixed by simply directing stderror of this line
 to /dev/null.
 ---
  contrib/completion/git-completion.bash |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/contrib/completion/git-completion.bash 
 b/contrib/completion/git-completion.bash
 index 2fece98..72251cc 100644
 --- a/contrib/completion/git-completion.bash
 +++ b/contrib/completion/git-completion.bash
 @@ -412,7 +412,7 @@ __git_refs_remotes ()
  __git_remotes ()
  {
 local i IFS=$'\n' d=$(__gitdir)
 -   test -d $d/remotes  ls -1 $d/remotes
 +   test -d $d/remotes  ls -1 $d/remotes 2/dev/null
 for i in $(git --git-dir=$d config --get-regexp 'remote\..*\.url' 
 2/dev/null); do
 i=${i#remote.}
 echo ${i/.url*/}
 --
 1.7.10.2 (Apple Git-33)

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

Re: [PATCH] contrib/completion: suppress stderror in bash completion of git remotes

2015-02-09 Thread Junio C Hamano 
Matt Korostoff mkorost...@gmail.com writes:

 In some system configurations there is a bug with the
 __git_remotes function.  Specifically, there is a problem
 with line 415, `test -d $d/remotes  ls -1 $d/remotes`.
 While `test -d` is meant to prevent listing the remotes
 directory if it does not exist, in some system, `ls` will
 run regardless.

What's some system?

Is this a platform's bug (e.g. test -d does not work correctly)?

Is this an configuration error of user's Git repository?

Is this something else?

I _think_ you would see the problem if $d/remotes is a directory
whose contents cannot be listed (e.g. chmod a= $d/remotes), and
that would not be a platform's bug (i.e. test -d would happily say
Yes there is a directory, and ls would fail with Permission
denied).  But I wonder if we rather want the user to notice that
misconfiguration so that the user can correct it, instead of hiding
the error message from ls.

 This results in an error in which typing `git push or` + `tab`
 prints out `ls: .git/remotes: No such file or directory`.
 This can be fixed by simply directing stderror of this line
 to /dev/null.
 ---
  contrib/completion/git-completion.bash |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/contrib/completion/git-completion.bash 
 b/contrib/completion/git-completion.bash
 index 2fece98..72251cc 100644
 --- a/contrib/completion/git-completion.bash
 +++ b/contrib/completion/git-completion.bash
 @@ -412,7 +412,7 @@ __git_refs_remotes ()
  __git_remotes ()
  {
   local i IFS=$'\n' d=$(__gitdir)
 - test -d $d/remotes  ls -1 $d/remotes
 + test -d $d/remotes  ls -1 $d/remotes 2/dev/null
   for i in $(git --git-dir=$d config --get-regexp 'remote\..*\.url' 
 2/dev/null); do
   i=${i#remote.}
   echo ${i/.url*/}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Junio C Hamano 
Paul E. McKenney paul...@linux.vnet.ibm.com writes:

 On Mon, Feb 09, 2015 at 12:57:11PM -0800, Junio C Hamano wrote:
 No, I do not think we have a way to blacklist certain recipient
 addresses from getting passed to the MTA, and I do not object to
 addition of such a mechanism if there is a valid need to do so.
 
 It feels a bit too convoluted to say Cc: to this address in the
 log message and then nonono, I do not want to send there, though.
 Why do you want to have Cc: in the log message if you do not want to
 send e-mail to that address in the first place?  Allowing the
 behaviour you are asking for would mean that those who see that the
 commit appeared on a branch would not be able to assume that the
 patch has already been sent to the stable review address, no?

 I could see where it might seem a bit strange.  ;-)

 The reason behind this is that you are not supposed to actually send
 email to the stable lists until after the patch has been accepted into
 mainline.  One way to make this work is of course to leave the stable
 Cc tags out of the commit log, and to manually send an email when the
 commit has been accepted.  However, this is subject to human error,
 and more specifically in this case, -my- human error.

 Hence the desire to have a Cc that doesn't actually send any email,
 but that is visible in mainline for the benefit of the scripts that
 handle the stable workflow.

So a configuration variable that you can set once and forget, e.g.

[sendemail]
blacklistedRecipients = sta...@vger.kernel.org

would not cut it, as you would _later_ want to send the e-mail once
the commit hits the mainline.  Am I reading you correctly?

Or is it that nobody actually sends to sta...@vger.kernel.org address
manually, but some automated process scans new commits that hit the
mainline and the string Cc: sta...@vger.kernel.org is used as a cue
for that process to pick them up?

--
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 2.2.2 annotate crash (strbuf.c:32)

2015-02-09 Thread Junio C Hamano 
Eric Sunshine sunsh...@sunshineco.com writes:

 There is a bit of suspicious code in builtin/blame.c where it is
 destroying the commit_info without ever initializing it,...

Good eyes.  I wonder why the compiler does not notice it.

It seems that this came from ea02ffa3 (mailmap:
simplify map_user() interface, 2013-01-05) and dates back to 1.8.2
or so.

 diff --git a/builtin/blame.c b/builtin/blame.c
 index 303e217..a3cc972 100644
 --- a/builtin/blame.c
 +++ b/builtin/blame.c
 @@ -2085,7 +2085,6 @@ static void find_alignment(struct scoreboard *sb, int 
 *option)
  
   for (e = sb-ent; e; e = e-next) {
   struct origin *suspect = e-suspect;
 - struct commit_info ci;
   int num;
  
   if (compute_auto_abbrev)
 @@ -2096,6 +2095,7 @@ static void find_alignment(struct scoreboard *sb, int 
 *option)
   if (longest_file  num)
   longest_file = num;
   if (!(suspect-commit-object.flags  METAINFO_SHOWN)) {
 + struct commit_info ci;
   suspect-commit-object.flags |= METAINFO_SHOWN;
   get_commit_info(suspect-commit, ci, 1);
   if (*option  OUTPUT_SHOW_EMAIL)
 @@ -2104,6 +2104,7 @@ static void find_alignment(struct scoreboard *sb, int 
 *option)
   num = utf8_strwidth(ci.author.buf);
   if (longest_author  num)
   longest_author = num;
 + commit_info_destroy(ci);
   }
   num = e-s_lno + e-num_lines;
   if (longest_src_lines  num)
 @@ -2113,8 +2114,6 @@ static void find_alignment(struct scoreboard *sb, int 
 *option)
   longest_dst_lines = num;
   if (largest_score  ent_score(sb, e))
   largest_score = ent_score(sb, e);
 -
 - commit_info_destroy(ci);
   }
   max_orig_digits = decimal_width(longest_src_lines);
   max_digits = decimal_width(longest_dst_lines);
--
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] contrib/completion: suppress stderror in bash completion of git remotes

2015-02-09 Thread Matt Korostoff 
In some system configurations there is a bug with the
__git_remotes function.  Specifically, there is a problem
with line 415, `test -d $d/remotes  ls -1 $d/remotes`.
While `test -d` is meant to prevent listing the remotes
directory if it does not exist, in some system, `ls` will
run regardless.

This results in an error in which typing `git push or` + `tab`
prints out `ls: .git/remotes: No such file or directory`.
This can be fixed by simply directing stderror of this line
to /dev/null.
---
 contrib/completion/git-completion.bash |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 2fece98..72251cc 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -412,7 +412,7 @@ __git_refs_remotes ()
 __git_remotes ()
 {
local i IFS=$'\n' d=$(__gitdir)
-   test -d $d/remotes  ls -1 $d/remotes
+   test -d $d/remotes  ls -1 $d/remotes 2/dev/null
for i in $(git --git-dir=$d config --get-regexp 'remote\..*\.url' 
2/dev/null); do
i=${i#remote.}
echo ${i/.url*/}
-- 
1.7.10.2 (Apple Git-33)

--
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] builtin/blame: destroy initialized commit_info only

2015-02-09 Thread Eric Sunshine 
Since ea02ffa3 (mailmap: simplify map_user() interface, 2013-01-05),
find_alignment() has been invoking commit_info_destroy() on an
uninitialized auto 'struct commit_info' (when METAINFO_SHOWN is not
set). commit_info_destroy() calls strbuf_release() for each of
'commit_info' strbuf member, which randomly invokes free() on whatever
random stack value happens to be reside in strbuf.buf, thus leading to
periodic crashes.

Reported-by: Dilyan Palauzov dilyan.palau...@aegee.org
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---

No test accompanying this fix since I don't know how to formulate one.

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

 builtin/blame.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/builtin/blame.c b/builtin/blame.c
index 303e217..a3cc972 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2085,7 +2085,6 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
 
for (e = sb-ent; e; e = e-next) {
struct origin *suspect = e-suspect;
-   struct commit_info ci;
int num;
 
if (compute_auto_abbrev)
@@ -2096,6 +2095,7 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
if (longest_file  num)
longest_file = num;
if (!(suspect-commit-object.flags  METAINFO_SHOWN)) {
+   struct commit_info ci;
suspect-commit-object.flags |= METAINFO_SHOWN;
get_commit_info(suspect-commit, ci, 1);
if (*option  OUTPUT_SHOW_EMAIL)
@@ -2104,6 +2104,7 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
num = utf8_strwidth(ci.author.buf);
if (longest_author  num)
longest_author = num;
+   commit_info_destroy(ci);
}
num = e-s_lno + e-num_lines;
if (longest_src_lines  num)
@@ -2113,8 +2114,6 @@ static void find_alignment(struct scoreboard *sb, int 
*option)
longest_dst_lines = num;
if (largest_score  ent_score(sb, e))
largest_score = ent_score(sb, e);
-
-   commit_info_destroy(ci);
}
max_orig_digits = decimal_width(longest_src_lines);
max_digits = decimal_width(longest_dst_lines);
-- 
2.3.0.rc2.191.g303d43c

--
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 00/11] Allow reference values to be checked in a transaction

2015-02-09 Thread Michael Haggerty 
On 02/09/2015 08:05 PM, Stefan Beller wrote:
 On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote:
 Michael Haggerty mhag...@alum.mit.edu writes:
 [...]
 This patch series applies on top of master merged together with
 sb/atomic-push, which in turn depends on mh/reflog-expire.

 I am a bit puzzled by your intentions, so help me out.

 I see that your understanding is that Stefan will be rerolling the
 push atomicity thing; wouldn't we then want to have a fix and
 clean topic like this one first and build the push atomicity thing
 on top instead?
 
 My understanding is to not reroll origin/sb/atomic-push, but
 origin/sb/atomic-push-fix (which is worded misleading. It is not about
 atomic pushes, but about enabling large transactions in my understanding)

Yes, that is what I thought.

 In other words, would it make sense to extend mh/reflog-expire (in
 'next') topic with commits from Fix some problems with reflog
 expiration (8 patches) series and this series to fix and clean it?

Both series have to do with reflogs, but they are logically pretty
independent. In particular, Fix some problems with reflog expiration
fixes problems that existed before mh/reflog-expire. And considering
that one topic is quite mature whereas the the other is just making its
debut, it seemed like yoking them together would slow down the first
topic for no good reason.

 I am not sure what advantages this would bring. A better history
 for bisection? I cannot speak for Michael, but my understanding was
 to have mh/reflog-expire and sb/atomic-push-fix merged now that 2.3
 is out and everything else on top is unclear/rerolled/discussed as needed.

Stefan, I think you mean sb/atomic-push, not sb/atomic-push-fix, right?

 We may even want to rebase/reroll mh/reflog-expire on top of v2.3
 while doing so to adjust to the transaction stuff, if that makes
 some of the changes in the two new series unnecessary (if these fix
 and clean up changes made in mh/reflog-expire in 'next', that is).

I see all of these topics as pretty independent, though given that they
touch similar areas of the code they often have annoying (but small)
conflicts with each other.

I expected that mh/reflog-expire and sb/atomic-push would be merged
pretty early in the 2.4 cycle (they are both in next already). Junio, is
that not your plan?

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Paul E. McKenney 
On Mon, Feb 09, 2015 at 12:57:11PM -0800, Junio C Hamano wrote:
 Paul E. McKenney paul...@linux.vnet.ibm.com writes:
 
  I need to be able to put the following Cc in a git commit:
 
  Cc: sta...@vger.kernel.org
 
  Yet I cannot allow git-send-email to actually send email to that address,
  lest I get an automated nastygram in response.  I found the --to-cmd=
  option to git-send-email, but it looks to only add email addresses, never
  delete them.  I also found the --suppress-cc= option to git-send-email,
  but it appears to suppress all Cc emails, not just selected ones.
 
  One approach that occurred to me is to hand-edit the files produced
  by git-format-patch, removing sta...@vger.kernel.org entirely prior to
  using git-send-email.  However, this is a bit error-prone.  Yes, I could
  script it, but with my luck, I will eventually end up having my script
  mangle some patch, for example to the Linux kernel's MAINTAINERS file.
  Furthermore, this approach means that people reviewing the patches
  cannot see the Cc stable entries (though I could presumably comment them
  out somehow).
 
  Another approach is to add the stable Ccs just before doing the pull
  request, by my upstream maintainer is not fond of that approach.  Nor am
  I, as it would be all to easy to forget to add the stable Ccs.  Or to
  get them wrong.
 
  I can't be the only person wanting to do something like this.  So is
  there some git option that I am missing here?
 
 No, I do not think we have a way to blacklist certain recipient
 addresses from getting passed to the MTA, and I do not object to
 addition of such a mechanism if there is a valid need to do so.
 
 It feels a bit too convoluted to say Cc: to this address in the
 log message and then nonono, I do not want to send there, though.
 Why do you want to have Cc: in the log message if you do not want to
 send e-mail to that address in the first place?  Allowing the
 behaviour you are asking for would mean that those who see that the
 commit appeared on a branch would not be able to assume that the
 patch has already been sent to the stable review address, no?

I could see where it might seem a bit strange.  ;-)

The reason behind this is that you are not supposed to actually send
email to the stable lists until after the patch has been accepted into
mainline.  One way to make this work is of course to leave the stable
Cc tags out of the commit log, and to manually send an email when the
commit has been accepted.  However, this is subject to human error,
and more specifically in this case, -my- human error.

Hence the desire to have a Cc that doesn't actually send any email,
but that is visible in mainline for the benefit of the scripts that
handle the stable workflow.

Thanx, Paul

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

Re: [PATCH] merge-file: correctly open files when in a subdir

2015-02-09 Thread Duy Nguyen 
On Sun, Feb 8, 2015 at 11:53 PM, Aleksander Boruch-Gruszecki
aleksander.boruchgrusze...@gmail.com wrote:
 run_setup_gently() is called before merge-file. This may result in changing
 current working directory, which wasn't taken into account when opening a file
 for writing.

 Fix by prepending the passed prefix. Previous var is left so that error
 messages keep referring to the file from the user's working directory
 perspective.

Sounds about right. Thomas Rast fixed something similar in 55846b9
(merge-file: correctly find files when called in subdir - 2010-10-17)
but he missed this part :-D. Perhaps a test case in
t/t6023-merge-file.sh to prove this patch is working?
-- 
Duy
--
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: low memory system to clone larger repo

2015-02-09 Thread Matt Sporleder 
A more final version of the tuning exercise I did is here:

http://mail-index.netbsd.org/tech-repository/2015/01/08/msg000520.html

I did try some of these setting on the server and it made the repo much much 
larger so I guess I am looking for ways to just reduce client memory usage/the 
best balance of disk, memory, and bandwidth. 

If there is a way to turn off some memory hogging speed ups I m interested in 
trying them. 

I will try to get you the output later since I have since started working on 
the server side.

Let me know if you want to try some server side stuff and I can give you a 
git:// or http:// off list. 

Thanks for looking, 
Matt


 On Feb 9, 2015, at 5:40 AM, Duy Nguyen pclo...@gmail.com wrote:
 
 On Thu, Jan 8, 2015 at 11:10 PM, matthew sporleder msporle...@gmail.com 
 wrote:
 I am attempting to clone this repo: https://github.com/jsonn/src/
 
 and have been successful on some lower memory systems, but i'm
 interested in continuing to push down the limit.
 
 I am getting more success running clone via https:// than git:// or
 ssh (which is confusing to me) and the smallest system that works is a
 raspberry pi with 256 RAM + 256 swap.
 
 I seem to run out of memory consistently around 16% into Resolving
 deltas phase but I don't notice an RSS jump so that's another
 confusing spot.
 
 Sorry for a really late reply. The command that's running when you run
 out of memory is index-pack. I guess it's verifying the delta chain. I
 think it needs enough memory for two uncompressed objects (or files)
 in a delta chain. I haven't finished cloning this repo yet so I don't
 know what these delta chains look like.
 
 What does it say when it runs out of memory? I'm thinking maybe we
 could force a core dump, then look at how memory is used.
 
 What if you git init, then do git fetch https://...; manually?
 There's an optimization for git-clone that may make index-pack use a
 bit more memory (and push it over the edge)
 
 My config is below and I'd appreciate any more suggestions of getting
 that down to working on a 128MB box (or smaller).
 
 I suppose it's ~/.gitconfig or /etc/gitconfig, it's not added after
 the clone is complete, correct? Sounds interesting, let me profile its
 memory usage..
 
 [pack]
windowMemory = 1m
packSizeLimit = 1m
deltaCacheSize = 1m
deltaCacheLimit = 10
packSizeLimit = 1m
 
 I think many of these only affect the server side. If you clone from
 github, then they are useless. You may want to provide your own server
 side with these settings and see if things change. Also play with
 pack.depth (affecting server side)
 
threads = 1
 -- 
 Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to rebase one branch of the merge commit?

2015-02-09 Thread Hans Ginzel 

On Sun, Feb 01, 2015 at 08:28:28PM +0100, Dennis Kaarsemaker wrote:

On zo, 2015-02-01 at 19:42 +0100, Hans Ginzel wrote:

Hello!

Suppose following git history:

A–M–C
  /
B

How to achieve this with commits metadata preserving?

A–M'–C'
  /
B'

I did

git checkout B
git add something_not_in_other_commits
git commit --amend

So I have B'. How to continue, please? My git version is 1.7.1 (Centos 6.5).


Assuming you have a branch pointing to C and no uncommitted changes:



1) git checkout branch-that-points-to-c
2) git rev-parse branch-that-point-to-c
3) git reset --hard A
4) git merge B'


This creates a new merge comit (M').


5) git cherry-pick sha1-that-was-the-output-of-step-2


This does nothing: Finished one cherry-pick. nothing to commit (working directory 
clean)

Thank you, but how to preserve date, message author of the original merge 
commit (M)
to the new one (M'), please?

Regards,
HG
--
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 2.2.2 annotate crash (strbuf.c:32)

2015-02-09 Thread Dilyan Palauzov 

Hello,

the point is that with exactly the same configuration on one computer 
there is crash and on another one things work just fine.


I found out that line builtin/blame.c:1675 makes the problems:

if (len) {
  printf(blame.c:1676, subject: %s, len: %i\n, subject, len);
--  strbuf_add(ret-summary, subject, len);  --
} else
   strbuf_addf(ret-summary, (%s), sha1_to_hex(commit-object.sha1));

commenting it out and compiling does not lead to crashing git anymore. 
You can find below the output of printf.


git clone git://git.cyrusimap.org/cyrus-imapd
git annotate timsieved/parser.c

*** Error in `git': double free or corruption (!prev): 
0x022e4b40 ***

=== Backtrace: =
/lib64/libc.so.6(+0x7ae36)[0x7f8f0fe2ce36]
/lib64/libc.so.6(+0x7bbb3)[0x7f8f0fe2dbb3]
git[0x41330b]
git[0x413cf6]
git[0x40f14f]
git[0x405ac5]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f8f0fdd3a25]
git[0x4069b1]
=== Memory map: 
0040-005e1000 r-xp  09:00 36163 
 /usr/bin/git
007e-007e1000 r--p 001e 09:00 36163 
 /usr/bin/git
007e1000-007e8000 rw-p 001e1000 09:00 36163 
 /usr/bin/git

007e8000-00823000 rw-p  00:00 0
021c1000-023e8000 rw-p  00:00 0 
 [heap]

7f8f07bc3000-7f8f07c04000 rw-p  00:00 0
7f8f07c23000-7f8f07c25000 rw-p  00:00 0
7f8f07c25000-7f8f07c51000 r--p  09:01 4594075 


/mnt/new/home/didopalauzov/cyrus-imapd/.git/objects/pack/pack-cdc8608c4304cfdf5bbe28257fef594357bdd721.pack
7f8f07c51000-7f8f07d2 r--p  09:01 4595166 


/mnt/new/home/didopalauzov/cyrus-imapd/.git/objects/pack/pack-2940fa128dee37fb4e0e5823cd6f9dff46da7c2b.pack
7f8f07d2-7f8f07ea1000 r--p  09:01 4595225 


/mnt/new/home/didopalauzov/cyrus-imapd/.git/objects/pack/pack-115dbdfb66491440464600a7ef7ab1f85b3ad170.pack
7f8f07ea1000-7f8f07fa6000 r--p  09:01 4595449 


/mnt/new/home/didopalauzov/cyrus-imapd/.git/objects/pack/pack-6278b37ee884848bb77280ddcd95700f9c933d87.pack
7f8f07fa6000-7f8f080b4000 r--p  09:01 4594150 


/mnt/new/home/didopalauzov/cyrus-imapd/.git/objects/pack/pack-dca01159e601a45ed0a79ad9844d621698c6aafd.pack
7f8f080b4000-7f8f0918c000 r--p  09:01 4594031 


/mnt/new/home/didopalauzov/cyrus-imapd/.git/objects/pack/pack-a918d22dbf1c50ae9bfcf479a84877cca3fae689.pack
7f8f0918c000-7f8f0944f000 r--p  09:01 4594554 


/mnt/new/home/didopalauzov/cyrus-imapd/.git/objects/pack/pack-a918d22dbf1c50ae9bfcf479a84877cca3fae689.idx
7f8f0944f000-7f8f0f998000 r--p  09:00 3719644 
 /lib64/locale/locale-archive
7f8f0f998000-7f8f0f99b000 r-xp  09:00 3719642 
 /lib64/libdl-2.17.so
7f8f0f99b000-7f8f0fb9a000 ---p 3000 09:00 3719642 
 /lib64/libdl-2.17.so
7f8f0fb9a000-7f8f0fb9b000 r--p 2000 09:00 3719642 
 /lib64/libdl-2.17.so
7f8f0fb9b000-7f8f0fb9c000 rw-p 3000 09:00 3719642 
 /lib64/libdl-2.17.so
7f8f0fb9c000-7f8f0fbb2000 r-xp  09:00 33467 
 /usr/lib64/libgcc_s.so.1
7f8f0fbb2000-7f8f0fdb1000 ---p 00016000 09:00 33467 
 /usr/lib64/libgcc_s.so.1
7f8f0fdb1000-7f8f0fdb2000 rw-p 00015000 09:00 33467 
 /usr/lib64/libgcc_s.so.1
7f8f0fdb2000-7f8f0ff58000 r-xp  09:00 3719720 
 /lib64/libc-2.17.so
7f8f0ff58000-7f8f10157000 ---p 001a6000 09:00 3719720 
 /lib64/libc-2.17.so
7f8f10157000-7f8f1015b000 r--p 001a5000 09:00 3719720 
 /lib64/libc-2.17.so
7f8f1015b000-7f8f1015d000 rw-p 001a9000 09:00 3719720 
 /lib64/libc-2.17.so

7f8f1015d000-7f8f10161000 rw-p  00:00 0
7f8f10161000-7f8f10178000 r-xp  09:00 3719597 
 /lib64/libpthread-2.17.so
7f8f10178000-7f8f10377000 ---p 00017000 09:00 3719597 
 /lib64/libpthread-2.17.so
7f8f10377000-7f8f10378000 r--p 00016000 09:00 3719597 
 /lib64/libpthread-2.17.so
7f8f10378000-7f8f10379000 rw-p 00017000 09:00 3719597 
 /lib64/libpthread-2.17.so

7f8f10379000-7f8f1037d000 rw-p  00:00 0
7f8f1037d000-7f8f10384000 r-xp  09:00 3719705 
 /lib64/librt-2.17.so
7f8f10384000-7f8f10583000 ---p 7000 09:00 3719705 
 /lib64/librt-2.17.so
7f8f10583000-7f8f10584000 r--p 6000 09:00 3719705 
 /lib64/librt-2.17.so
7f8f10584000-7f8f10585000 rw-p 7000 09:00 3719705 
 /lib64/librt-2.17.so
7f8f10585000-7f8f10587000 r-xp  09:00 37211 
 /usr/lib64/libcharset.so.1.0.0
7f8f10587000-7f8f10786000 ---p 2000 09:00 37211 
 /usr/lib64/libcharset.so.1.0.0
7f8f10786000-7f8f10787000 r--p 1000 09:00 37211 
 /usr/lib64/libcharset.so.1.0.0
7f8f10787000-7f8f10788000 rw-p 2000 09:00 37211 
 /usr/lib64/libcharset.so.1.0.0
7f8f10788000-7f8f10949000 r-xp  09:00 34361 
 /usr/lib64/libcrypto.so.1.0.0
7f8f10949000-7f8f10b49000 ---p 001c1000 09:00 34361 
 /usr/lib64/libcrypto.so.1.0.0
7f8f10b49000-7f8f10b71000 rw-p 001c1000 09:00 34361 
 /usr/lib64/libcrypto.so.1.0.0

7f8f10b71000-7f8f10b74000 rw-p  00:00 0
7f8f10b74000-7f8f10b9 r-xp  09:00 215770 
 /usr/lib/libz.so.1.2.8
7f8f10b9-7f8f10d8f000 ---p 0001c000 09:00 215770 
 /usr/lib/libz.so.1.2.8
7f8f10d8f000-7f8f10d9 r--p 0001b000 09:00 215770

Re: low memory system to clone larger repo

2015-02-09 Thread Duy Nguyen 
On Thu, Jan 8, 2015 at 11:10 PM, matthew sporleder msporle...@gmail.com wrote:
 I am attempting to clone this repo: https://github.com/jsonn/src/

 and have been successful on some lower memory systems, but i'm
 interested in continuing to push down the limit.

 I am getting more success running clone via https:// than git:// or
 ssh (which is confusing to me) and the smallest system that works is a
 raspberry pi with 256 RAM + 256 swap.

 I seem to run out of memory consistently around 16% into Resolving
 deltas phase but I don't notice an RSS jump so that's another
 confusing spot.

Sorry for a really late reply. The command that's running when you run
out of memory is index-pack. I guess it's verifying the delta chain. I
think it needs enough memory for two uncompressed objects (or files)
in a delta chain. I haven't finished cloning this repo yet so I don't
know what these delta chains look like.

What does it say when it runs out of memory? I'm thinking maybe we
could force a core dump, then look at how memory is used.

What if you git init, then do git fetch https://...; manually?
There's an optimization for git-clone that may make index-pack use a
bit more memory (and push it over the edge)

 My config is below and I'd appreciate any more suggestions of getting
 that down to working on a 128MB box (or smaller).

I suppose it's ~/.gitconfig or /etc/gitconfig, it's not added after
the clone is complete, correct? Sounds interesting, let me profile its
memory usage..

 [pack]
 windowMemory = 1m
 packSizeLimit = 1m
 deltaCacheSize = 1m
 deltaCacheLimit = 10
 packSizeLimit = 1m

I think many of these only affect the server side. If you clone from
github, then they are useless. You may want to provide your own server
side with these settings and see if things change. Also play with
pack.depth (affecting server side)

 threads = 1
-- 
Duy
--
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] Geolocation support

2015-02-09 Thread Ævar Arnfjörð Bjarmason 
On Mon, Feb 9, 2015 at 2:24 AM, Junio C Hamano gits...@pobox.com wrote:
 In case I was not clear, I do not think it is likely for us to accept
 a patch that mucks with object header fields with this information.
 Have them in the log text and let UI interpret them.

We've already told clients for a long time to ignore fields they don't
know about, why would we not store what's intended to be
machine-readable key-value pair data in the commit object itself, as
opposed to sticking it in the log message where parsing it is always
going to be a bit more tricky  distracting, since users will have to
look at this arbitrary metadata when they do git log or git show.
--
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] gitk: Remove tcl-format flag from a message that shouldn't have it

2015-02-09 Thread Junio C Hamano 
Alex Henrie alexhenri...@gmail.com writes:

 This is just a friendly reminder that this patch has been sitting in
 the mailing list archives for a couple of weeks, and it has not yet
 been accepted or commented on.

I think that is because the message was not sent to the right
people, and also because the patch was made against a wrong project
;-).

I'll forward it to the gitk maintainer after digging it out of the
archive and tweaking it.  Thanks.

Paul, comments?

-- 8 --
From: Alex Henrie alexhenri...@gmail.com
Date: Thu, 22 Jan 2015 01:19:39 -0700
Subject: gitk: Remove tcl-format flag from a message that shouldn't have it

xgettext sees % o and interprets it as a placeholder for an octal
number preceded by a space. However, in this case it's not actually a
placeholder, and most translations will replace the % o sequence with
something else. Removing the tcl-format flag from this string prevents
tools like Poedit from freaking out when % o doesn't appear in the
translated string.

The corrected flag will appear in each translation's po file the next time
the translation is updated with `make update-po`.

Signed-off-by: Alex Henrie alexhenri...@gmail.com
---
 gitk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gitk b/gitk
index 78358a7..dfd458d 100755
--- a/gitk
+++ b/gitk
@@ -11237,6 +11237,7 @@ proc prefspage_general {notebook} {
 ${NS}::label $page.maxwidthl -text [mc Maximum graph width (lines)]
 spinbox $page.maxwidth -from 0 -to 100 -width 4 -textvariable maxwidth
 grid $page.spacer $page.maxwidthl $page.maxwidth -sticky w
+ #xgettext:no-tcl-format
 ${NS}::label $page.maxpctl -text [mc Maximum graph width (% of pane)]
 spinbox $page.maxpct -from 1 -to 100 -width 4 -textvariable maxgraphpct
 grid x $page.maxpctl $page.maxpct -sticky w
-- 
2.2.2
--
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] gitk: Remove tcl-format flag from a message that shouldn't have it

2015-02-09 Thread Alex Henrie 
Hi,

This is just a friendly reminder that this patch has been sitting in
the mailing list archives for a couple of weeks, and it has not yet
been accepted or commented on.

-Alex
--
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: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Paul E. McKenney 
On Mon, Feb 09, 2015 at 01:46:10PM -0800, Junio C Hamano wrote:
 Paul E. McKenney paul...@linux.vnet.ibm.com writes:
 
   Hence the desire to have a Cc that doesn't actually send any email,
   but that is visible in mainline for the benefit of the scripts that
   handle the stable workflow.
  
  So a configuration variable that you can set once and forget, e.g.
  
  [sendemail]
 blacklistedRecipients = sta...@vger.kernel.org
  
  would not cut it, as you would _later_ want to send the e-mail once
  the commit hits the mainline.  Am I reading you correctly?
 
  This would actually work for me.  Once the patch is accepted into
  mainline, I am done with it.  So I should -never- send email to
  sta...@vger.kernel.org, unless I am doing so manually, for example because
  I forgot to add the stable tag to a given commit.  But in that case,
  I would just use mutt to forward the patch to sta...@vger.kernel.org,
  and git would not be involved.
 
 OK, thanks, we have a workable design to let us move forward, then.
 
 Gits, any takers?

Would it help if I offered a beer?  ;-)

Thanx, Paul

--
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 17/21] list-files: show directories as well as files

2015-02-09 Thread Junio C Hamano 
Nguyễn Thái Ngọc Duy  pclo...@gmail.com writes:

 + if (show_dirs strchr(ce-name, '/') 

Oops.  Will fix it up locally.
--
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] builtin/blame: destroy initialized commit_info only

2015-02-09 Thread Eric Sunshine 
On Mon, Feb 9, 2015 at 4:28 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
 Since ea02ffa3 (mailmap: simplify map_user() interface, 2013-01-05),
 find_alignment() has been invoking commit_info_destroy() on an
 uninitialized auto 'struct commit_info' (when METAINFO_SHOWN is not
 set). commit_info_destroy() calls strbuf_release() for each of

s/each of/each/

...despite several proof-reads (sigh).

 'commit_info' strbuf member, which randomly invokes free() on whatever
 random stack value happens to be reside in strbuf.buf, thus leading to
 periodic crashes.

 Reported-by: Dilyan Palauzov dilyan.palau...@aegee.org
 Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gmail Message rejection

2015-02-09 Thread Stefan Beller 
Hi Erik,

this is not a bug but a feature. ;) Actually rejecting HTML is one of
the easiest ways to avoid 95 % of spam mails. If you want email to
send via gmail, you can do so by enabling text only mode for sending
mails.

That is good for general discussion. But if you intend to send a
patch, beware! gmail as well as most of other mail clients wrap text
on their on (optimized for human readability), but a patch needs to
go through unchanged that it applies on the receiving side cleanly.
Therefore I'd recommend setting up git send-email, which does exactly
what git needs and wants for sending patches.



2015-02-09 12:14 GMT-08:00  e...@aercon.net:
 Can I submit this as a bug report, that sending something from the gmail
 client results in this response?

 Delivery to the following recipient failed permanently:

  git@vger.kernel.org

 Technical details of permanent failure:
 Google tried to deliver your message, but it was rejected by the server for
 the recipient domain vger.kernel.org by vger.kernel.org. [209.132.180.67].

 The error that the other server returned was:
 550 5.7.1 Content-Policy reject msg: The message contains HTML subpart,
 therefore we consider it SPAM or Outlook Virus.  TEXT/PLAIN is accepted.!
 BF:H 0.338318; S932497AbbBIUIh

 --
 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
--
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: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Paul E. McKenney 
On Mon, Feb 09, 2015 at 01:17:05PM -0800, Junio C Hamano wrote:
 Paul E. McKenney paul...@linux.vnet.ibm.com writes:
 
  On Mon, Feb 09, 2015 at 12:57:11PM -0800, Junio C Hamano wrote:
  No, I do not think we have a way to blacklist certain recipient
  addresses from getting passed to the MTA, and I do not object to
  addition of such a mechanism if there is a valid need to do so.
  
  It feels a bit too convoluted to say Cc: to this address in the
  log message and then nonono, I do not want to send there, though.
  Why do you want to have Cc: in the log message if you do not want to
  send e-mail to that address in the first place?  Allowing the
  behaviour you are asking for would mean that those who see that the
  commit appeared on a branch would not be able to assume that the
  patch has already been sent to the stable review address, no?
 
  I could see where it might seem a bit strange.  ;-)
 
  The reason behind this is that you are not supposed to actually send
  email to the stable lists until after the patch has been accepted into
  mainline.  One way to make this work is of course to leave the stable
  Cc tags out of the commit log, and to manually send an email when the
  commit has been accepted.  However, this is subject to human error,
  and more specifically in this case, -my- human error.
 
  Hence the desire to have a Cc that doesn't actually send any email,
  but that is visible in mainline for the benefit of the scripts that
  handle the stable workflow.
 
 So a configuration variable that you can set once and forget, e.g.
 
 [sendemail]
   blacklistedRecipients = sta...@vger.kernel.org
 
 would not cut it, as you would _later_ want to send the e-mail once
 the commit hits the mainline.  Am I reading you correctly?

This would actually work for me.  Once the patch is accepted into
mainline, I am done with it.  So I should -never- send email to
sta...@vger.kernel.org, unless I am doing so manually, for example because
I forgot to add the stable tag to a given commit.  But in that case,
I would just use mutt to forward the patch to sta...@vger.kernel.org,
and git would not be involved.

So as far as I can see, yes, it would be perfectly OK to unconditionally
blacklist sta...@vger.kernel.org within my git tree.  That would be nice!

 Or is it that nobody actually sends to sta...@vger.kernel.org address
 manually, but some automated process scans new commits that hit the
 mainline and the string Cc: sta...@vger.kernel.org is used as a cue
 for that process to pick them up?

I belive that something like this happens, but I don't know the details. 
I do know that it does not involve any of my local git trees.  ;-)

Thanx, Paul

--
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: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Jonathan Nieder 
Hi,

Paul E. McKenney wrote:

 Cc: sta...@vger.kernel.org

 Yet I cannot allow git-send-email to actually send email to that address,
 lest I get an automated nastygram in response.

Interesting.  Last time this came up, the result seemed to be
different[*].

Thanks,
Jonathan

[*] http://thread.gmane.org/gmane.comp.version-control.git/178926/focus=178929
--
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: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Junio C Hamano 
Paul E. McKenney paul...@linux.vnet.ibm.com writes:

  Hence the desire to have a Cc that doesn't actually send any email,
  but that is visible in mainline for the benefit of the scripts that
  handle the stable workflow.
 
 So a configuration variable that you can set once and forget, e.g.
 
 [sendemail]
  blacklistedRecipients = sta...@vger.kernel.org
 
 would not cut it, as you would _later_ want to send the e-mail once
 the commit hits the mainline.  Am I reading you correctly?

 This would actually work for me.  Once the patch is accepted into
 mainline, I am done with it.  So I should -never- send email to
 sta...@vger.kernel.org, unless I am doing so manually, for example because
 I forgot to add the stable tag to a given commit.  But in that case,
 I would just use mutt to forward the patch to sta...@vger.kernel.org,
 and git would not be involved.

OK, thanks, we have a workable design to let us move forward, then.

Gits, any takers?


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

EOL handling (EGit/svn/Windows)

2015-02-09 Thread Piotr Krukowiecki 
Hi,

in short: how to do svn-git conversion, or how to configure git/EGit
so that Windows/Linux users are happy with EOLs?


Long story:

recently I converted (with git-svn) an svn repository to git. This
created git repository with Windows (CRLF) end of line files. I
suppose the original svn repository had Windows EOLs (I did the
conversion on linux). The development is done in Eclipse (mostly on
Windows), so the EGit is a natural choice for git client.

But the problem appears: what should be the core.eol and core.autocrlf settings?

EGit seems to have problems with core.autocrlf=true - it always
converts files to LF on commit. So if someone modifies one line in a
file which was not modified yet since the git-svn conversion, each
line is seen as modified (CRLF changed to LF). It seems like a bug in
EGit - git-config man page says files that contain CRLF in the
repository will not be touched for core.autocrlf=true. Normal
command line git works better - if a file has CRLF in it in
repository, it will not convert it (it will convert new files from
CRLF to LF though - that's OK).

I could also set core.autocrlf=false which should avoid any conversion
to LF on check-in. This will move the responsibility of using correct
EOL to users. Everyone, both Windows and Linux users, will have to use
the same EOLs. Probably core.eol will have to be set to crlf, the same
as in repo. But I suppose this will not work - new files will be
created with native EOLs so the files will end up being checked in
like that. I also think it might create some problems with programs
not accepting non-native EOLs. On the other hand, it would prevent
problems caused by CRLF-LF conversion on binary files incorrectly
detected as text files...

So maybe I should re-write the repository (all the history) so that
the files are converted to LF? (examples:
http://superuser.com/questions/293941/rewrite-git-history-to-replace-all-crlf-to-lf
http://blog.gyoshev.net/2013/08/normalizing-line-endings-in-git-repositories/).This
way I should be able to use core.autocrlf for both git and EGit.
That's what I'm favoring currently. The downside is that, if I assume
correctly that SVN repo kept files in CRLF format, the conversion to
LF might break something (not sure what - some UTF files? or some
unexpected stuff...).

This re-writing of repo would not be needed if EGit did work like
normal git... should I drop EGit? I would prefer not to :(

Any other suggestions?

BTW, core.autocrlf documentation in git-config is a bit hard to
understand... it's not obvious what it affects - working dir? commits?
Does it convert to CRLF or LF? What is the input setting (what is
output conversion)?  I found some explanation here:
http://thread.gmane.org/gmane.comp.version-control.git/174413


Thanks,
-- 
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: [PATCH 11/24] untracked cache: load from UNTR index extension

2015-02-09 Thread Junio C Hamano 
Nguyễn Thái Ngọc Duy  pclo...@gmail.com writes:

 +static int read_one_dir(struct untracked_cache_dir **untracked_,
 + struct read_data *rd)
 +{
 +#define NEXT(x) \
 + next = data + (x); \
 + if (next  rd-end) \
 + return -1;

Please do not do this, and instead write them at two places they are
used.  It is not clear to those who are reading the use sites that
this can break the control flow and return to the caller.

--
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: low memory system to clone larger repo

2015-02-09 Thread Duy Nguyen 
On Thu, Jan 8, 2015 at 11:10 PM, matthew sporleder msporle...@gmail.com wrote:
 I am attempting to clone this repo: https://github.com/jsonn/src/

This repo has 3.4M objects. Basic book keeping would cost 200MB (in
practice it'll be higher because I'm assuming no deltas in my
calculation). On my 64-bit system, it already uses 400+ MB at the
beginning of delta resolving phase, and is about 500MB during. 32-bit
systems cost less but I doubt we could keep it within 256 MB limit. I
think you just need more powerful machines for a repo this size.

Also, they have some large files (udivmodti4_test.c 16MB, MD5SUMS
6MB..) These giant files could make index-pack use more memory
especially if they are deltified. If you repack the repo with
core.bigFileThreshold about 1-2MB, then clone, you may get a better
memory consumption, but at the cost of bigger packs.
-- 
Duy
--
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 rebase' silently drops changes?

2015-02-09 Thread Johannes Sixt 
Am 09.02.2015 um 13:53 schrieb Sergey Organov:
 Johannes Sixt j...@kdbg.org writes:
 
 Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth:
 On 06.02.2015 22:28, Sergey Organov wrote:

 # Now rebase my work.
 git rebase -f HEAD~1

 # What? Where is my Precious change in a???
 cat a
 /SCRIPT

 I.e., the modification marked [!] was silently lost during rebase!

 Just a wild guess: Maybe because you omitted -p / --preserve-merges
 from git rebase?

 No, that would not help. --preserve-merges repeats the merge, but does
 not apply the amendment.
 
 Really? Why? Here the valid concern you gave below doesn't even apply!

--preserve-merges was bolted on to git-rebase. The first implementation
just re-computed the merge, and rebase would be interrupted if the merge
was not clean. This was good enough for many.

Later --preserve-merges was abused to replay not only integration
branches, but branchy history in general. At that time, the feature was
deemed wide spread enough that changing its behavior was a no-go.

There you have it.

If you want a version of --preserve-merges that does what *you* need,
consider this commit:

  git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent

Use it like this:

  git rebase -i -p --first-parent ...

Beware, its implementation is incomplete: if the rebase is interrupted,
then 'git rebase --continue' behaves as if --first-parent were not given.

 it is impossible for git rebase to decide to which rebased
 commit the amendement applies. It doesn't even try to guess. It's the
 responsibility of the user to apply the amendment to the correct
 commit.
 
 Yeah, this sounds reasonable, /except/ git even gives no warning when it
 drops amendments. Shouldn't 'git rebase' rather consider merge amendment
 a kind of conflict?

There is work in progress where a merge is computed entirely in-memory
(without relying on files in the worktree). It could be used to detect
whether there are any changes beyond the automatic merge results, and
they could be warned about.

-- Hannes

--
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] index-pack: reduce memory footprint a bit

2015-02-09 Thread Junio C Hamano 
Nguyễn Thái Ngọc Duy  pclo...@gmail.com writes:

 For each object in the input pack, we need one struct object_entry. On
 x86-64, this struct is 64 bytes long. Although:

  - The 8 bytes for delta_depth and base_object_no are only useful when
show_stat is set. And it's never set unless someone is debugging.

  - The three fields hdr_size, type and real_type take 4 bytes each
even though they never use more than 4 bits.

 By moving delta_depth and base_object_no out of struct object_entry
 and make the other 3 fields one byte long instead of 4, we shrink 25%
 of this struct.

 On a 3.4M object repo that's about 53MB. The saving is less impressive
 compared to index-pack total memory use (about 400MB before delta
 resolving, so the saving is just 13%)

 Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
 ---
  I'm not sure if this patch is worth pursuing. It makes the code a
  little bit harder to read. I was just wondering how much memory could
  be saved..

I would say 13% is already impressive ;-).

I do not find the result all that harder to read.  I however think
that the change would make it a lot harder to maintain, especially
because the name object-entry-extra does not have any direct link
to show-stat to hint us that this must be allocated when show-stat
is in use and must never be looked at when show-stat is not in use.

Also it makes me wonder if the compilers are smart enough to notice
that the codepaths that access objects_extra[] are OK because they
are all inside if (show_stat).
--
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] builtin/blame: destroy initialized commit_info only

2015-02-09 Thread Eric Sunshine 
On Mon, Feb 9, 2015 at 4:33 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
 On Mon, Feb 9, 2015 at 4:28 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
 Since ea02ffa3 (mailmap: simplify map_user() interface, 2013-01-05),
 find_alignment() has been invoking commit_info_destroy() on an
 uninitialized auto 'struct commit_info' (when METAINFO_SHOWN is not
 set). commit_info_destroy() calls strbuf_release() for each of

 s/each of/each/

 ...despite several proof-reads (sigh).

 'commit_info' strbuf member, which randomly invokes free() on whatever
 random stack value happens to be reside in strbuf.buf, thus leading to

s/to be/to/

(sigh again)

 periodic crashes.

 Reported-by: Dilyan Palauzov dilyan.palau...@aegee.org
 Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Greg KH 
On Mon, Feb 09, 2015 at 03:35:37PM -0800, Paul E. McKenney wrote:
 On Mon, Feb 09, 2015 at 01:53:50PM -0800, Jonathan Nieder wrote:
  Hi,
  
  Paul E. McKenney wrote:
  
   Cc: sta...@vger.kernel.org
  
   Yet I cannot allow git-send-email to actually send email to that address,
   lest I get an automated nastygram in response.
  
  Interesting.  Last time this came up, the result seemed to be
  different[*].
 
 Hmmm...  Greg KH didn't say there were no automated nastygrams, just
 that he wasn't worried about it.
 
 I can try it on the next to-be-backported commit and see what happens.

There are no automated nastygrams, it's a hit this key to send out
this form message I have in my email client.

The only time it triggers a false-positive is when I haven't had enough
coffee in the morning, which is what happened recently with a patch from
John Stultz.  If I've sent you that message incorrectly, I'm sorry,
please let me know.

Again, any patch cc:ed to stable that has a stable mark on it in the
signed-off-by area is fine, and it helps me to know to watch out for
things when they hit Linus's tree, or most importantly, to notice if
they somehow _don't_ hit his tree.  Again, some recent patches from John
fall in to that category, they didn't make it into Linus's tree when
they probably should have for 3.19, and now I need to scoop them up
quickly when they finally do.  If I hadn't been cc:ed on them, I would
not have noticed that.

Hope this helps explain things,

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

Re: [PATCH] contrib/completion: suppress stderror in bash completion of git remotes

2015-02-09 Thread Matt Korostoff 
Thank you for your detailed reply Junio.  I'll try to address your
concerns individually, but let me also offer a general thought that
this is probably a good use case to handle even if the root cause is
solvable outside of git.  That is to say, I would think we'd still
want git autocompletion working for users running on imperfect
platforms.

 What's some system?

My apologies, that was a typo. I meant to write some systems.  I'm
not sure what the root cause is, but I can tell you I'm running a
rather vanilla development environment (git 1.7.10, bash 3.2, osx
10.8).  I wish I could supply a list of the version combinations that
result in such an event, but I'm not sure how I would do acquire a
list like that.

 Is this a platform's bug (e.g. test -d does not work correctly)?

I don't believe so—here's a simple test-of-the-test I threw together
https://gist.github.com/MKorostoff/f203e414847d43b21de4 which does not
throw this error.

 Is this an configuration error of user's Git repository?

I think I have a pretty generic git configuration (here it is, though
note I've had to redact some identifying information
https://gist.github.com/MKorostoff/f8358f72b968249a3925).  Still, I'd
think we would want to handle such a misconfiguration explicitly,
rather than throw a seemingly unrelated error during autocompletion

 Is this something else?

It would be very helpful if you could supply a few more details on the
type of something you're looking for

 I _think_ you would see the problem if $d/remotes is a directory
 whose contents cannot be listed

I can confirm, that is indeed the behavior.  Animated gif example here
http://i.imgur.com/qcPxAub.gif

 But I wonder if we rather want the user to notice that
 misconfiguration so that the user can correct it

While I wholeheartedly agree that such user feedback would be
valuable, I'm just not sure that it makes sense for this feedback to
interrupt the user's typing mid-word.

Sorry if anyone receives this twice, my first attempt to send was
rejected for including HTML.

On Mon, Feb 9, 2015 at 4:09 PM, Junio C Hamano gits...@pobox.com wrote:
 Matt Korostoff mkorost...@gmail.com writes:

 In some system configurations there is a bug with the
 __git_remotes function.  Specifically, there is a problem
 with line 415, `test -d $d/remotes  ls -1 $d/remotes`.
 While `test -d` is meant to prevent listing the remotes
 directory if it does not exist, in some system, `ls` will
 run regardless.

 What's some system?

 Is this a platform's bug (e.g. test -d does not work correctly)?

 Is this an configuration error of user's Git repository?

 Is this something else?

 I _think_ you would see the problem if $d/remotes is a directory
 whose contents cannot be listed (e.g. chmod a= $d/remotes), and
 that would not be a platform's bug (i.e. test -d would happily say
 Yes there is a directory, and ls would fail with Permission
 denied).  But I wonder if we rather want the user to notice that
 misconfiguration so that the user can correct it, instead of hiding
 the error message from ls.

 This results in an error in which typing `git push or` + `tab`
 prints out `ls: .git/remotes: No such file or directory`.
 This can be fixed by simply directing stderror of this line
 to /dev/null.
 ---
  contrib/completion/git-completion.bash |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/contrib/completion/git-completion.bash 
 b/contrib/completion/git-completion.bash
 index 2fece98..72251cc 100644
 --- a/contrib/completion/git-completion.bash
 +++ b/contrib/completion/git-completion.bash
 @@ -412,7 +412,7 @@ __git_refs_remotes ()
  __git_remotes ()
  {
   local i IFS=$'\n' d=$(__gitdir)
 - test -d $d/remotes  ls -1 $d/remotes
 + test -d $d/remotes  ls -1 $d/remotes 2/dev/null
   for i in $(git --git-dir=$d config --get-regexp 'remote\..*\.url' 
 2/dev/null); do
   i=${i#remote.}
   echo ${i/.url*/}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 'git rebase' silently drops changes?

2015-02-09 Thread Sergey Organov 
Johannes Sixt j...@kdbg.org writes:

 Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth:
 On 06.02.2015 22:28, Sergey Organov wrote:
 
 # Now rebase my work.
 git rebase -f HEAD~1

 # What? Where is my Precious change in a???
 cat a
 /SCRIPT

 I.e., the modification marked [!] was silently lost during rebase!
 
 Just a wild guess: Maybe because you omitted -p / --preserve-merges
 from git rebase?

 No, that would not help. --preserve-merges repeats the merge, but does
 not apply the amendment.

Really? Why? Here the valid concern you gave below doesn't even apply!

Check... yes, git silently drops amend even with --preserve-merges
(script to reproduce at the end[1])! How comes?

 It's just how rebase works: It omits merge commits when it linearizes
 history.

 Sergey, it is impossible for git rebase to decide to which rebased
 commit the amendement applies. It doesn't even try to guess. It's the
 responsibility of the user to apply the amendment to the correct
 commit.

Yeah, this sounds reasonable, /except/ git even gives no warning when it
drops amendments. Shouldn't 'git rebase' rather consider merge amendment
a kind of conflict?


[1] To reproduce amend drop by git rebase --preserve-merges:

SCRIPT
git init t
cd t
git config rerere.enabled false # doesn't actually matter either way.

echo I  a; git add a
echo I  b; git add b
git commit -aqm I
git tag start

git checkout -b test

echo B  b; git commit -m B -a

git checkout master

echo A  a
git commit -aqm A

git merge --no-edit test
git branch -d test

# Clean merge, but result didn't compile, so I fixed it and
# amended the merge:
echo Precious!  a # [!] This is modification that gets lost
git commit --amend --no-edit -aq
cat a

# Make a change earlier in history, to rebase my work on top of it.
git co -q start
git co -b test
echo C  c; git add c
git commit -aqm C

# Now rebase my work.
git co master
git rebase --preserve-merges --no-fork-point test

# What? Where is my Precious change in a???
cat a

/SCRIPT

-- Sergey.
--
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] index-pack: reduce memory footprint a bit

2015-02-09 Thread Nguyễn Thái Ngọc Duy 
For each object in the input pack, we need one struct object_entry. On
x86-64, this struct is 64 bytes long. Although:

 - The 8 bytes for delta_depth and base_object_no are only useful when
   show_stat is set. And it's never set unless someone is debugging.

 - The three fields hdr_size, type and real_type take 4 bytes each
   even though they never use more than 4 bits.

By moving delta_depth and base_object_no out of struct object_entry
and make the other 3 fields one byte long instead of 4, we shrink 25%
of this struct.

On a 3.4M object repo that's about 53MB. The saving is less impressive
compared to index-pack total memory use (about 400MB before delta
resolving, so the saving is just 13%)

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 I'm not sure if this patch is worth pursuing. It makes the code a
 little bit harder to read. I was just wondering how much memory could
 be saved..

 We could maybe save some more by splitting union delta_base with the
 assumption that pack-objects would utilize delta-ofs-offset as much
 as possible, which makes the delta_base.sha1[] a waste most of the
 time.
 
 This repo has 2803447 deltas, and because it's a clone case, all
 delta should be ofs-delta, which means we waste about 32MB. But
 shrinking this could get ugly.

 builtin/index-pack.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 4632117..479ec5e 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -18,9 +18,12 @@ static const char index_pack_usage[] =
 struct object_entry {
struct pack_idx_entry idx;
unsigned long size;
-   unsigned int hdr_size;
-   enum object_type type;
-   enum object_type real_type;
+   unsigned char hdr_size;
+   char type;
+   char real_type;
+};
+
+struct object_entry_extra {
unsigned delta_depth;
int base_object_no;
 };
@@ -64,6 +67,7 @@ struct delta_entry {
 };
 
 static struct object_entry *objects;
+static struct object_entry_extra *objects_extra;
 static struct delta_entry *deltas;
 static struct thread_local nothread_data;
 static int nr_objects;
@@ -873,13 +877,15 @@ static void resolve_delta(struct object_entry *delta_obj,
void *base_data, *delta_data;
 
if (show_stat) {
-   delta_obj-delta_depth = base-obj-delta_depth + 1;
+   int i = delta_obj - objects;
+   int j = base-obj - objects;
+   objects_extra[i].delta_depth = objects_extra[j].delta_depth + 1;
deepest_delta_lock();
-   if (deepest_delta  delta_obj-delta_depth)
-   deepest_delta = delta_obj-delta_depth;
+   if (deepest_delta  objects_extra[i].delta_depth)
+   deepest_delta = objects_extra[i].delta_depth;
deepest_delta_unlock();
+   objects_extra[i].base_object_no = j;
}
-   delta_obj-base_object_no = base-obj - objects;
delta_data = get_data_from_pack(delta_obj);
base_data = get_base_data(base);
result-obj = delta_obj;
@@ -902,7 +908,7 @@ static void resolve_delta(struct object_entry *delta_obj,
  * want; if so, swap in set and return true. Otherwise, leave it untouched
  * and return false.
  */
-static int compare_and_swap_type(enum object_type *type,
+static int compare_and_swap_type(char *type,
 enum object_type want,
 enum object_type set)
 {
@@ -1499,7 +1505,7 @@ static void show_pack_info(int stat_only)
struct object_entry *obj = objects[i];
 
if (is_delta_type(obj-type))
-   chain_histogram[obj-delta_depth - 1]++;
+   chain_histogram[objects_extra[i].delta_depth - 1]++;
if (stat_only)
continue;
printf(%s %-6s %lu %lu %PRIuMAX,
@@ -1508,8 +1514,8 @@ static void show_pack_info(int stat_only)
   (unsigned long)(obj[1].idx.offset - obj-idx.offset),
   (uintmax_t)obj-idx.offset);
if (is_delta_type(obj-type)) {
-   struct object_entry *bobj = 
objects[obj-base_object_no];
-   printf( %u %s, obj-delta_depth, 
sha1_to_hex(bobj-idx.sha1));
+   struct object_entry *bobj = 
objects[objects_extra[i].base_object_no];
+   printf( %u %s, objects_extra[i].delta_depth, 
sha1_to_hex(bobj-idx.sha1));
}
putchar('\n');
}
@@ -1672,6 +1678,8 @@ int cmd_index_pack(int argc, const char **argv, const 
char *prefix)
curr_pack = open_pack_file(pack_name);
parse_pack_header();
objects = xcalloc(nr_objects + 1, sizeof(struct object_entry));
+   if (show_stat)
+   objects_extra = xcalloc(nr_objects + 1, sizeof(struct 
object_entry_extra));

Re: [PATCH] builtin/blame: destroy initialized commit_info only

2015-02-09 Thread Jeff King 
On Mon, Feb 09, 2015 at 04:28:07PM -0500, Eric Sunshine wrote:

 Since ea02ffa3 (mailmap: simplify map_user() interface, 2013-01-05),
 find_alignment() has been invoking commit_info_destroy() on an
 uninitialized auto 'struct commit_info' (when METAINFO_SHOWN is not
 set). commit_info_destroy() calls strbuf_release() for each of
 'commit_info' strbuf member, which randomly invokes free() on whatever
 random stack value happens to be reside in strbuf.buf, thus leading to
 periodic crashes.
 
 Reported-by: Dilyan Palauzov dilyan.palau...@aegee.org
 Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
 ---
 
 No test accompanying this fix since I don't know how to formulate one.
 
 Discussion: http://thread.gmane.org/gmane.comp.version-control.git/263534

Thanks, good catch. This is almost certainly the source of the reported
bug. I was curious why we didn't find this until now, and what we could
do to detect similar problems. You can stop reading if you're not
interested. :)

We call strbuf_release on each of the uninitialized components. That
will only call free(sb-buf) if sb-alloc is non-zero. And if sb-buf is
0, then that is OK (it is a noop to free NULL). So the bug only shows
itself when the uninitialized memory is such that both are non-zero.

We're in a loop here, where we set the METAINFO_SHOWN to avoid
processing commits from the loop twice. So generally the first time
through the loop (when we really do have uninitialized crap in the
struct), that flag will not be set, and we will fill in the struct. Then
a later iteration of the loop does have the flag set, and does not fill
in the struct. But quite often we'll have whatever was left in the
struct from the previous loop iteration. Which, because strbuf_release()
re-initializes the strbufs, is a valid strbuf which it is a noop to
free.

Of course, that's entirely up to the compiler. It's reasonable to use
the same block for the variable in each iteration of the loop, but it is
free to do whatever it likes. It may even come and go with various
optimization settings.

Obviously if we hit a compiler that feeds the uninitialized values to
free(), this is pretty easy to detect with valgrind or another
heap-checking library. But let's assume we have a compiler that does the
reuse behavior. There's no bug in the generated code, but it's
technically undefined behavior. Can we detect it?

The compiler _could_ know statically that this is a use of uninitialized
memory, except that it only sees:

commit_info_destroy(ci);

on the uninitialized memory. Since we are passing a pointer to a
function it can't see, it has to assume that it's actually initializing
the memory for us (i.e., it looks the same as commit_info_init). So it
doesn't catch it. I don't know of a way to annotate the pointers better,
or if there is a way to get the compiler to see the code in a more
global way.

Valgrind cannot detect this. With the reuse behavior, we never even
call malloc, so there's nothing for it to see there. We are accessing
uninitialized memory, but it's on the stack. Valgrind doesn't even know
about it, or that we are looping here.

Clang's address sanitizer has compiler support, so it does get to see
this memory and could put a canary value in for each loop iteration. But
it doesn't. Instead, you're supposed to use the memory sanitizer to
catch uninitialized memory.

I tried that, but got overwhelmed with false positives. Like valgrind,
it has problems accepting that memory written by zlib is actually
initialized. But in theory, if we went to the work to annotate some
false positives, it should be able to find this problem.

-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: Is there some way to suppress Cc email only to stable?

2015-02-09 Thread Paul E. McKenney 
On Mon, Feb 09, 2015 at 01:53:50PM -0800, Jonathan Nieder wrote:
 Hi,
 
 Paul E. McKenney wrote:
 
  Cc: sta...@vger.kernel.org
 
  Yet I cannot allow git-send-email to actually send email to that address,
  lest I get an automated nastygram in response.
 
 Interesting.  Last time this came up, the result seemed to be
 different[*].

Hmmm...  Greg KH didn't say there were no automated nastygrams, just
that he wasn't worried about it.

I can try it on the next to-be-backported commit and see what happens.

Thanx, Paul

 Thanks,
 Jonathan
 
 [*] http://thread.gmane.org/gmane.comp.version-control.git/178926/focus=178929
 

--
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] builtin/blame: destroy initialized commit_info only

2015-02-09 Thread Jeff King 
On Mon, Feb 09, 2015 at 06:24:35PM -0500, Jeff King wrote:

 Clang's address sanitizer has compiler support, so it does get to see
 this memory and could put a canary value in for each loop iteration. But
 it doesn't. Instead, you're supposed to use the memory sanitizer to
 catch uninitialized memory.
 
 I tried that, but got overwhelmed with false positives. Like valgrind,
 it has problems accepting that memory written by zlib is actually
 initialized. But in theory, if we went to the work to annotate some
 false positives, it should be able to find this problem.

I got rid of the false positives here, through a combination of
compiling with NO_OPENSSL (since it otherwise doesn't know that
git_SHA1_Final is initializing hashes), and this patch which lets it
assume that the output of zlib (at least for these cases) is always
initialized:

diff --git a/sha1_file.c b/sha1_file.c
index 30995e6..28c8f84 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1682,6 +1682,7 @@ unsigned long get_size_from_delta(struct packed_git *p,
git_zstream stream;
int st;
 
+   memset(delta_head, 0, 20);
memset(stream, 0, sizeof(stream));
stream.next_out = delta_head;
stream.avail_out = sizeof(delta_head);
@@ -1973,6 +1974,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
buffer = xmallocz_gently(size);
if (!buffer)
return NULL;
+   memset(buffer, 0, size);
memset(stream, 0, sizeof(stream));
stream.next_out = buffer;
stream.avail_out = size + 1;


Sadly, though, the test case in question runs to completion. It does not
seem to detect our use of uninitialized memory. :(

-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 00/11] Allow reference values to be checked in a transaction

2015-02-09 Thread Stefan Beller 
On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote:
 Michael Haggerty mhag...@alum.mit.edu writes:

 The main purpose of this series is to simplify the interface to
 reference transactions as follows:

 * Remove the need to supply an explicit have_old parameter to
   ref_transaction_update() and ref_transaction_delete(). Instead,
   check the old_sha1 if and only if it is non-NULL.

 * Allow NULL to be supplied to ref_transaction_update() as new_sha1,
   in which case old_sha1 will be verified under lock, but the
   reference's value will not be altered.

 * Add a function ref_transaction_verify(), which verifies the current
   value of a reference without changing it.

 * Make the similarity between ref_transaction_update() and
   update_ref() more obvious.

 Along the way, it fixes a race that could happen if two processes try
 to create an orphan commit at the same time.

 This patch series applies on top of master merged together with
 sb/atomic-push, which in turn depends on mh/reflog-expire.

 I am a bit puzzled by your intentions, so help me out.

 I see that your understanding is that Stefan will be rerolling the
 push atomicity thing; wouldn't we then want to have a fix and
 clean topic like this one first and build the push atomicity thing
 on top instead?

My understanding is to not reroll origin/sb/atomic-push, but
origin/sb/atomic-push-fix (which is worded misleading. It is not about
atomic pushes, but about enabling large transactions in my understanding)


 In other words, would it make sense to extend mh/reflog-expire (in
 'next') topic with commits from Fix some problems with reflog
 expiration (8 patches) series and this series to fix and clean it?

I am not sure what advantages this would bring. A better history
for bisection? I cannot speak for Michael, but my understanding was
to have mh/reflog-expire and sb/atomic-push-fix merged now that 2.3
is out and everything else on top is unclear/rerolled/discussed as needed.


 We may even want to rebase/reroll mh/reflog-expire on top of v2.3
 while doing so to adjust to the transaction stuff, if that makes
 some of the changes in the two new series unnecessary (if these fix
 and clean up changes made in mh/reflog-expire in 'next', that 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