[BUG] git rebase: fatal: Not a valid object name: ''

[Andreas Krey]

Hi, everyone,

since ad8261d (rebase: use reflog to find common base with upstream)
a rebase without arguments says fatal: Not a valid object name: '',
caused by trying to determine the fork point with an empty $switch_to.

I don't really see what the appropriate fix would be. :-(

Andreas

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

Re: [BUG] git rebase: fatal: Not a valid object name: ''

[Andreas Krey]

On Thu, 09 Jan 2014 15:56:21 +, John Keeping wrote:
...
 I think the correct fix is to change the $switch_to in the call to
 git merge-base --fork-point to ${switch_to:-HEAD}, but I'm not at a
 machine where I can test that or work up a patch at the moment...

Thanks, looks plausible and works. Need to catch train myself now.

Andreas

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

Re: Consistency question

[Andreas Krey]

On Wed, 15 Jan 2014 12:40:29 +, David Kastrup wrote:
...
 With a single root, depth helps a lot.  When looking for a common
 parent of a number of commits, you first shorten all ancestries to the
 same size and then you can look for the point of convergence in
 lockstep.

Hmm, how about traversing from all the start commits downwards
simultaneously, noting which start you say each commit from, and stopping
when you have a commit carrying all start labels?

I don't quite see how the same size plus lockstep works out (but the
'same size' part is possibly the same as my 'concurrent traversal').

 But didn't git forego the single root requirement in its commit DAG at
 some point of time?

About at the beginning, I guess. Nothing in the data model ever required it?

 ... The rest is just idle curiosity.

Me too, mostly. I may have to do some traversal for tree/dag painting.

Andreas

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

Re: Consistency question

[Andreas Krey]

On Wed, 15 Jan 2014 14:00:30 +, David Kastrup wrote:
 Andreas Krey a.k...@gmx.de writes:
...
  Hmm, how about traversing from all the start commits downwards
  simultaneously, noting which start you say each commit from, and stopping
  when you have a commit carrying all start labels?
 
 It means that when the start commits are at considerably different
 depth, you'll traverse much more material than necessary.

But it has the advantage that you don't need to traverse the DAG
to the root when the differences are small - the runtimes are roughly
proportional to the difference between the commits.

 Also you need labels.

Yes, I assume that that (marking commits) is not a cost factor.

  I don't quite see how the same size plus lockstep works out (but the
  'same size' part is possibly the same as my 'concurrent traversal').
 
 It just equalizes the depth before starting, so you don't need labels:
 any common ancestor is reached at the same time by its descendants.
 
 Of course, I conveniently forgot merge commits.

I finally noticed but forgot to mention in the last post.

Merges also mean that there is not necessarily a unique common
ancestor between commits.

Andreas

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

Bug: git repack keeps temps on ENOSPC

[Andreas Krey]

Hi,

I noticed that, when a git repack fails due to insufficient
disk space, the newly created partial pack file isn't unlinked
(which doesn't help at all in that situation).

(Will venture a look myself when time permits.)

Andreas

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

egit vs. git behaviour (was: [RFC/WIP] Pluggable reference backends)

[Andreas Krey]

On Mon, 10 Mar 2014 19:39:00 +, Shawn Pearce wrote:
 Yes, this was my real concern. Eclipse users using EGit expect EGit to
 be compatible with git-core at the filesystem level so they can do
 something in EGit then switch to a shell and bang out a command, or
 run a script provided by their project or co-worker.

A question: Where to ask/report problems with that?

We're currently running into problems that egit doesn't push to where
git would when the local and remote branches aren't the same name. It
seems that egit ignores the branch.*.merge settings. Or push.default?

Andreas

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

Re: Silly time stamps

[Andreas Krey]

On Wed, 09 Apr 2014 20:50:57 +, Mahmoud Asshole wrote:
...
 This was raised previously[1], but none of the responses are convincing.

Please go directly to the special hell of debugging timezone-related stuff
in customer data, for which this extra bit of information is heaven-sent.
Do not collect additional bile, and do not reappear here.

Andreas

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

Re: What is missing from Git v2.0

[Andreas Krey]

On Wed, 23 Apr 2014 22:35:55 +, Felipe Contreras wrote:
...
 Anyway, if you disagree change one of your frequently used passwords to a
 chapter of The Lord of the Rings for a day. Let's see if you still think that.

Proving that one extreme isn't the optimum doesn't prove the other is.

Andreas

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

Re: Pull is Evil

[Andreas Krey]

On Thu, 01 May 2014 16:21:42 +, Marc Branchaud wrote:
...
 
 But these days there's hardly any risk to using a detached HEAD.  Plus
 nowadays I think it's commonly accepted that using topic branches is a git
 best practice.  The notion of doing work on a generically-named branch like
 maint seems archaic.
 
 So what benefit does git pull provide?

It provides the moral equivalent of 'cvs update', 'svn update', and
'clearcase do nothing'.

Even when I'm on a feature branch, there are cases where I have that branch
as the current one in multiple repos (on different machines because testing),
or multiple people working on that branch. A 'git pull' is the obvious way
to get divergent branches back together.

In cvssvn a local workspace can't ever be more than half a commit ahead,
and what an 'update' does is most similar to a rebase in git. But I'm
not eager to teach this future userbase rebases, and also a rebase loses
expensive test results that are tied to the commit ids.

My personal beef with 'git pull' is still that sometimes (namely in the
'git pull  git push' sequence) it should reverse the order of the
parents in the merge commit, so that *my* commits look like an
integrated topic branch, instead of the former mainline.

Unfortunately the answers to the question what to do instead of 'git
pull' are, in increasing order of teaching needed:

- Ok, just 'git pull' sigh.

- Please do a 'git pull --rebase'; I'll show you how.

- Something involving switching branches and doing the
   merge in the other direction

(I'm coming from a 'blessed repo where everybody pushes to' setup,
and we're considering a server trigger that refuses pushes where
the previous head is not a *first* parent of the new head, in order
not to accidentally mess up the mainline.)

Andreas

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

Re: Pull is Evil

[Andreas Krey]

On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote:
...
 I didn't mean replace 'pull' with 'update' everywhere.  I meant
 Introduce 'update' that lets integrate your history into that from
 the remote, which is to integrate in a direction opposite from how
 'pull' does.  

That still doesn't quite solve my problem. If I'm tracking origin/master
in a local master branch, I can just use 'git pull' to get my 'feature'
branch (which is named master) updated to the current state of the origin.
This amounts to 'integrating' origin/master into my master.

When I finally want to deliver and push to origin/master, I put on the
integrator's hat, and I cat do a 'git update' that will do the merge
in reverse, and push the result to origin/master. The result will look
like origin pulled my master branch into his.

Problem is that whether to use pull or update depends on whether I
intend to push afterwards; and additionally, if I can push fast-forward
without needing to 'git update' the integration into origin/master will
look weird.

(Oh, and please don't name it 'update' - we have an important alias
of that name.)

Andreas

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

Re: Pull is Evil

[Andreas Krey]

On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote:
...
 What the gibbins?  I don't even use git pull.

I do, but I watch for the fast-forward message
and undo as appropriate.

 I use git fetch, and then, depending on my needs, I rebase or merge.

I wouldn't mind that, but I have a century of newbies who are used
to having other people's changes appear in their workspace without
any interaction. Teaching them the mainline thing (aka first-parent)
and the commands to properly mergepush is...tricky.

And that goes for every user base, so some improvement would be
greatly appreciated.

Andreas

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

Re: Stop prepending /usr/bin to hooks PATH, or document it very clearly

[Andreas Krey]

On Fri, 17 Oct 2014 13:25:42 +, Ciro Santilli wrote:
...
 The problem is that the `/usr/bin` breaks interpreter version manager
 systems like RVM, rbenv, virtualenv, etc. since people will write
 hooks like:
 
 #!/usr/bin/env ruby
 
 and the `/usr/bin` ruby will get run instead of the managed one

And that is the right thing to do. What ruby to execute with is
a property of the hook script, not of the virtualenv a user happens
to be in. If you want virtualenvs, you should set up the right one
within the hook script.

...
 - documenting this behavior *very* clearly on `man githooks`

That would still be a good thing to do.

Andreas

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

Priming git clone with a local repo?

[Andreas Krey]

Hi, dear listers,

I'm wondering if there is (or will be) a way of doing almost

  git clone --reference localrepo host:canonrep

Basically, I don't want the implications of --reference but still the
performance advantages of reusing local objects/pack files. I probably
have to go and first do a

  git clone -s -n localrepo canonrepo

and then go into canonrepo, fix up the remote, fetch, and properly
reset the local branch. Is there an easier way of doing a
--reference-but-hardlink-objects-instead-of-setting-alternate
within git? Or implementing it?

Andreas

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

Re: Remote's 'currently active branch' not HEAD?

[Andreas Krey]

On Tue, 03 Sep 2013 12:46:52 +, Andreas Krey wrote:
...
 I have a strange behaviour from a bare repo I inherited;
 when I clone from that one (ssh) the branch checked out
 is *not* the one referenced in HEAD in the remote repo,

I now have a sample repo that reproduces this behaviour.
Unpack tar file, clone, see clone having 'wrong' branch
checked out, apparently independent of the transport:

  wget http://abox.h.apk.li/clot.tar
  tar xvf clot.tar
  (cd clot  git branch -a)  # Current branch is 'r1'
  git clone clot c1
  (cd c1  git branch -a)# Current branch is 'aa'?

Same with git v1.7.1.x and v1.8.4.

Andreas

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

Re: Remote's 'currently active branch' not HEAD?

[Andreas Krey]

On Tue, 03 Sep 2013 13:48:31 +, Andreas Krey wrote:
...
 I now have a sample repo that reproduces this behaviour.
 Unpack tar file, clone, see clone having 'wrong' branch
 checked out, apparently independent of the transport:

Ouch, it looks like 'git clone' doesn't actually know
the 'current remote branch' but picks one of those that
happen to have the HEAD *commit* as their tip.

At least the 'git clone' doc would be misleading then.

Andreas

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

Re: Remote's 'currently active branch' not HEAD?

[Andreas Krey]

On Tue, 03 Sep 2013 15:02:50 +, Michael Schubert wrote:
...
  happen to have the HEAD *commit* as their tip.
 
 Yes, it picks the first of those:
 
 http://thread.gmane.org/gmane.comp.version-control.git/168144

Thanks for the pointer.

And pity, the patches didn't make it that time either...

Andreas

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

Re: Remote's 'currently active branch' not HEAD?

[Andreas Krey]

On Tue, 03 Sep 2013 08:33:39 +, Junio C Hamano wrote:
...
 Reading the patch series from 2008 again, I do agree with J6t's
 comment that it should be just a regular capability,

I've implemented it as a 'sym=refs/heads/foo' capability.
It actually makes the patch series a lot shorter; the only
thing I don't get running is the t5601-clone.sh test case.

If I run the exact same commands in a shell script they succeed,
in t5601-clone.sh the clone step seems to fail, and I have no
clue where to look for a clue.

Any pointers?

Andreas

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

Re: Remote's 'currently active branch' not HEAD?

[Andreas Krey]

On Fri, 06 Sep 2013 13:41:30 +, Andreas Krey wrote:
...
 If I run the exact same commands in a shell script they succeed,
 in t5601-clone.sh the clone step seems to fail, and I have no
 clue where to look for a clue.

Oh, never mind. --verbose shows that the test is borked;
it tries a checkout into an already-existing dir. Patch
coming up soon.

Andreas

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

[PATCH 1/3] upload-pack: send the HEAD information

[Andreas Krey]

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

This implements the server side of protocol extension to show which branch
the HEAD points at.  The information is sent as a capability symref=target.

Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andreas Krey a.k...@gmx.de
---
 upload-pack.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index 127e59a..390d1ec 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -745,13 +745,17 @@ static int send_ref(const char *refname, const unsigned 
char *sha1, int flag, vo
if (mark_our_ref(refname, sha1, flag, cb_data))
return 0;
 
-   if (capabilities)
-   packet_write(1, %s %s%c%s%s%s agent=%s\n,
+   if (capabilities) {
+   unsigned char dummy[20];
+   const char *target = resolve_ref_unsafe(HEAD, dummy, 0, NULL);
+   packet_write(1, %s %s%c%s%s%s%s%s agent=%s\n,
 sha1_to_hex(sha1), refname_nons,
 0, capabilities,
 allow_tip_sha1_in_want ?  allow-tip-sha1-in-want 
: ,
 stateless_rpc ?  no-done : ,
+target ?  symref= : , target ? target : 0,
 git_user_agent_sanitized());
+   }
else
packet_write(1, %s %s\n, sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
-- 
1.8.3.1.485.g9704416.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Unconfuse git clone when two branches at are HEAD.

[Andreas Krey]

Ok, here are some patches that make git actually
check out the current remote branch when cloning.

Up to now this failed when there were two branches that pointed to 
the HEAD commit of the remote repo, and git clone would sometimes
choose the wrong one as the HEAD ref isn't transmitted in all
transport.

Stuff the HEAD ref into the capability list (assuming refs are clean 
enough to do that w/o escaping), and read them out on the other
side. All other things were thankfully already in place.

Two of the patches have Junio in the From as they are essentially his.

Andreas
--
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/3] connect.c: save symref info from server capabilities

[Andreas Krey]

Signed-off-by: Andreas Krey a.k...@gmx.de
---
 connect.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/connect.c b/connect.c
index a0783d4..98c4868 100644
--- a/connect.c
+++ b/connect.c
@@ -72,8 +72,8 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t 
src_len,
for (;;) {
struct ref *ref;
unsigned char old_sha1[20];
-   char *name;
-   int len, name_len;
+   char *name, *symref;
+   int len, name_len, symref_len;
char *buffer = packet_buffer;
 
len = packet_read(in, src_buf, src_len,
@@ -94,9 +94,12 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t 
src_len,
name = buffer + 41;
 
name_len = strlen(name);
+   symref = 0;
if (len != name_len + 41) {
free(server_capabilities);
server_capabilities = xstrdup(name + name_len + 1);
+   symref = parse_feature_value(server_capabilities,
+symref, symref_len);
}
 
if (extra_have 
@@ -108,6 +111,10 @@ struct ref **get_remote_heads(int in, char *src_buf, 
size_t src_len,
if (!check_ref(name, name_len, flags))
continue;
ref = alloc_ref(buffer + 41);
+   if (symref) {
+   ref-symref = xcalloc(symref_len + 1, 1);
+   strncpy(ref-symref, symref, symref_len);
+   }
hashcpy(ref-old_sha1, old_sha1);
*list = ref;
list = ref-next;
-- 
1.8.3.1.485.g9704416.dirty

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

[PATCH 3/3] clone: test the new HEAD detection logic

[Andreas Krey]

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

Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andreas Krey a.k...@gmx.de
---
 t/t5601-clone.sh | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..ccda6df 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -285,4 +285,15 @@ test_expect_success NOT_MINGW,NOT_CYGWIN 'clone local path 
foo:bar' '
git clone ./foo:bar foobar
 '
 
+test_expect_success 'clone from a repository with two identical branches' '
+
+   (
+   cd src 
+   git checkout -b another master
+   ) 
+   git clone src target-11 
+   test z$( cd target-11  git symbolic-ref HEAD ) = zrefs/heads/another
+
+'
+
 test_done
-- 
1.8.3.1.485.g9704416.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] connect.c: save symref info from server capabilities

[Andreas Krey]

On Fri, 06 Sep 2013 10:56:51 +, Junio C Hamano wrote:
 Andreas Krey a.k...@gmx.de writes:
 
...
  +   if (symref) {
  +   ref-symref = xcalloc(symref_len + 1, 1);
  +   strncpy(ref-symref, symref, symref_len);
  +   }
...
 
 This looks utterly wrong.  HEAD may happen to be the first ref that
 is advertised and hence capability list typically comes on it, but
 that does not necessarily have to be the case from the protocol's
 correctness point of view.

Ok, then I misunderstood that part. I thought we'd be going to
put the symref (if any) into 'capabilities' on the respective ref,
but putting them all in one capability list sounds saner all in all.

 I think this function should do this instead.
 
 - inside the loop, collect the symref=... capabilities;
 
 - after the loop, look at the symref=... capabilities, and
   among the refs the loop added to the *list, find the HEAD
   ref and set its -symref to point at an appropirate ref.

Fair game. There goes the parse_feature_value; will have to iterate
another way (or look them (symref=#{name}:) up instead of collecting
them into a hash beforehand).

Can I assume that the only capability list is always on the
first ref sent (as it is now)?

(And besides, is there something more suitable for the 
 xcalloc/strncpy combination?)

Andreas

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

Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.

[Andreas Krey]

On Mon, 09 Sep 2013 07:44:04 +, Junio C Hamano wrote:
...
 I'd rather not go this route.  Allowing refs/heads/master and local
 branches that forked from it in refs/heads/master/{a,b,c,...} could
 be a potentially useful future enhancement,

Want! We're currently going the route of naming the branches

  master
  feature/master
  feature/subfeature/master

to allow feature/subfeature/topic, and feature/subfeature in the first place.

(Other hierarchy separator candidates were ugly, shell-unwieldy, already
commonly used within branch names, or illegal.)

Andreas

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

Re: [Proposal] Clonable scripts

[Andreas Krey]

On Mon, 09 Sep 2013 22:48:42 +, Niels Basjes wrote:
...
 However I can imagine that a malicious opensource coder can create a
 github repo and try to hack the computer of a contributer via those
 scripts. So having such scripts is a 'bad idea'.

Given that half the repos out there are cloned to 'make install' in
them...it's still a bad idea.

 If those scripts were how ever written in a language that is build
 into the git program and the script are run in such a way that they
 can only interact with the files in the local git (and _nothing_
 outside of that) this would be solved.

I still think this is a nightmare of maintenance. You'd need a restricted
version of a language that doesn't allow access outside the repo (and
no TCP either), and someone will always miss some module...

Not that it wouldn't be cool, yet.

...
 Like I said, this is just a proposal and I would like to know what you
 guys think.

I think there are generally two use cases:

- Many people working on repos in an organization. Give them a wrapper
  script that does the clone (and also knows the clone URL already),
  that will set up hooks and configuration as needed.

- github-style cooperation. Add a make hooks to your Makefile that sets
  up the hooks your project seems to want. After all, this is for the
  developers to pre-check what they will submit, so it is in their own
  interest to have (and cross-read) the hooks.

Andreas

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

java zlib woes (was: Reading commit objects)

[Andreas Krey]

On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote:
 Ok, we discovered that the commit object actually contains the tree
 object's sha1, by reading its contents with python zlib library.
 
 So the bug must be with our java code (we're building a java lib).

That's interesting. We ran in a similar problem: We had a fetch
with jget hanging within the zlib deflater code in what looked
like a busy loop. Unfortunately we don't yet have a publishable
repo on which this happens.

Andreas
--
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/3] Fixing volatile HEAD in push.default = current

[Andreas Krey]

On Thu, 23 May 2013 13:25:55 +, Ramkumar Ramachandra wrote:
 Junio C Hamano wrote:
  I have largedir I want to get rid of, but there is a directory
  I want to save, largedir/precious, in it, so I do
 
  cp -R largedir/precious precious
 
  and then run 'rm -rf largedir' in another terminal in parallel.

'mv largedir/precious precious; rm -rf largedir'? No race here.

...
 Consider a slightly different example: I rename a file while having an
 active file handle open in a process that's reading the file.  Will
 the rename fail or will the fread() in the process fail?  Nope, both
 work fine.  Replace rename with remove, and we still have the same
 answer.  Ofcourse there are no guarantees: I can start up another
 process to overwrite the sectors corresponding to that file's data
 with zeros; unless the complete file is there in the kernel buffer, a
 read() will eventually end up slurping in the zeros (or fail?), right?

Oh, there are guarantees, they just don't include the case where you
take a shotgun to the disk. (Or do it on an nfs mount and delete the
file from another machine.)

...

Andreas

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

Re: first parent, commit graph layout, and pull merge direction

[Andreas Krey]

On Wed, 22 May 2013 11:07:07 +, Junio C Hamano wrote:
...
 If you have a four-commit segment in your commit ancestry graph

I never had yet. :-(

 (time flows from left to right; turn your head 90-degrees to the
 right if you want a gitk representation):
 
 ---A--X
 \/
 /\
 ---B--Y
 
 where X and Y are both merges between A and B, having A as their
 first parent, how would you express such a graph with first-parent
 chain going a straight line?

Of course there are multiple possible straight lines and how it looks
depends on the order I use the existing heads to fish them out. (That
is, when the straight lines join, I need to bend one of them.) Assuming
I take the one where X is on, I expect a look like

-A---X-
  \  |
   +- Y
  |  |
-B+--+

Branch heads that are reachable from other head are picked after those
that aren't reachable.

The point is to get the feature branches being displayed on separate
lanes (and thus visibly sticking out) and not being intermingled with
the longer-living branches.

...
 Don't do that, then.

:-) Problem is, in this case 'I' expands to about
17 people I need to educate on this.

Andreas

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

Re: first parent, commit graph layout, and pull merge direction

[Andreas Krey]

On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote:
...
 This is a feature of `git pull` that I really despise.  I really wish
 `git pull` treated the remote as the first parent in its merge
 operation.

I'd actually only like it that way when pulling from
the tracking branch, not for any pull.

Andreas

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

Re: first parent, commit graph layout, and pull merge direction

[Andreas Krey]

On Thu, 23 May 2013 06:34:38 +, Felipe Contreras wrote:
...
 I don't understand; gitk already shows the first parent starting from
 the bottom, and the merge commits arrive from the right side. What am
 I missing?

That this isn't (consistently) the case in complicated situations.
I'll need to make a picture (as in png).

Andreas

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

Re: first parent, commit graph layout, and pull merge direction

[Andreas Krey]

On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote:
...
 ...
  Don't do that, then.

Ouch, you're right. The problem is not actually in the
pull; only the *last* pull into a feature branch that
then get pushed back ff to master needs to be reversed.

And at that time you don't know it's the last one
- swap parents before the push if necessary.

Andreas

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

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

[Andreas Krey]

On Thu, 23 May 2013 07:45:34 +, Junio C Hamano wrote:
...
 Even with 'mv', between the time the main in mv starts and the
 process finally issues rename(2) on the directory, you can start
 running what competes and interferes with it in another terminal,
 so it does not fundamentally change anything, I would have to say.

Not fundamentally, it's just that the mv is fast enough you wouldn't
even think of switch to another term/backgrounding it.

Andreas

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

Re: Feature Request: existence-only tracking

[Andreas Krey]

On Thu, 23 May 2013 12:01:43 +, Brett Trotter wrote:
 In my work, we have a lot of autogenerated files that need to exist so
 a script will replace their contents, but tracking the contents
 creates a lot of unnecessary conflicts. I would love to see an option
 for a different tracking method that just makes sure a file or
 directory exists.

You could probably do this via the clean/smugde filters via .gitattributes.

But really this loooks like suboptimal build design. You should change
the generator to not require an (empty/) file beforehand, or change
the build process to create those files before invoking the generator.
(Likewise empty directories that are neeed in the build should be
created by the build, not by the versioning system.)

All IMHO.

Andreas

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

Re: first parent, commit graph layout, and pull merge direction

[Andreas Krey]

On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote:
...
 Here is an idea (probably already discussed in the long history of git):
 1) the branch name is recorded in a commit (for merges the branch that 
 is updated)

The branch name is almost completely meaningless. I could just
do my feature in my local master and never have a different name.

Or commit something onto tmp that I then fast-forward into my
(properly named) feature branch.

 2) unique identifier of repository is recorded in commit (optional)

That is pure noise (in my workflow).

 3) simple configurable ordering and/or coloring scheme in gitk based on 
 committer,branch name and repo (with wildcards).

Ok, gitk could use some features. :-)

...
 Is this a bad idea or just no one did it yet?

Possibly not bad (hg does parts of it), but un-git-ish?

(I'm not sure that it was *intended* that the parents
of a merge commit have an order, except that they need
to for deterministic hashes.)

Andreas

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

Re: first parent, commit graph layout, and pull merge direction

[Andreas Krey]

On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote:
...
 Instead of having a nice these six commits marked as 'x' were done
 on a branch forked some time ago, to address only this one issue and
 to address it fully history that explains how these commits were
 related and these commits are the full solution to a single issue:
 
   x---x---x---x---x---x
  / \
  ---o---o---o---o---o---o---M---o---o---...
 
 they end up with something like this, even with the flip the heads
 of a merge option, by pulling too often:
 
   x---x   x---x---x   x
  / \ / \ / \
  ---o---o---M---o---o---M---M---o---o---...

Wouldn't that be (you don't want to put your work back into master before
it's done) the following?

   x---x---M---x---x---M--x
  /   /   /\
  ---o---o---M---o---o---M--o---M---o---o---...

With a bit of luck the first-parent strands will also run like this.

I know that rebasing topic branches is better than updating, but my
monetary upstream is busy letting go a clearcase-minted mindset.
Teaching them rebasing will take a while, and as long as tthat we
will have the picture above.

Andreas

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

Re: first parent, commit graph layout, and pull merge direction

[Andreas Krey]

On Fri, 24 May 2013 17:05:26 +, Holger Hellmuth (IKS) wrote:
 Am 24.05.2013 15:42, schrieb Andreas Krey:
...
 The branch name is almost completely meaningless. I could just
 do my feature in my local master and never have a different name.
 
 In which case parent switching in the commit wouldn't help you either.

Oh, it does; I tried. Names are meaningless, the parent ordering
isn't. ( [And at least, it's already in there.]

 But even you could keep your master always on the left side of gitk if 
 you deem it special. And you could keep longer running cooperative 
 branches (the main develop and the release branch of your project for 
 example) in a seperate lane.

I need gitk (or similar) to do it. Will take some time to understand
the code (and triggers the 'I can write it (the interesting part) faster
than I can grok gitk').

...
 Without additional information about the commit history gitk can do 
 exactly what it does now.

Most definitely not. There are quite some situations where the graph
deteriorates pretty heavily, even when not expecting it to pay attention
to first parent. When you have two branches, of which one regularly
gets merge into the other, it sometimes manages to display first the
one, then the other branch, with a log of merge edges going upwards
in parallel, for example.

Andreas

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

Re: java zlib woes (was: Reading commit objects)

[Andreas Krey]

On Tue, 21 May 2013 22:56:21 +, Shawn Pearce wrote:
...
 This was with JGit?  A stack trace and JGit version (so we can
 correlate line numbers) would be a much more useful bug report than
 nothing at all.

I now have a full test case (involving a generated repo just shy of 1GB)
that will reproduce that hang. Will look up the existing jgit bug to
report there.

Andreas

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

Re: git-daemon: needs /root/.config/git/config?

[Andreas Krey]

On Wed, 05 Jun 2013 13:19:18 +, Ian Kumlien wrote:
...
 Well, I have no idea of how to control HOME in xinetd - access to the
 machine is limited and x doesn't give that much access (nothing really
 important is actually stored in /root)

Make xinetd execute '/usr/bin/env HOME=/home/yourstruly git ...'
instead of 'git ...'.

Andreas

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

Re: [PATCH 2/3] Move copy_note_for_rewrite + friends from builtin/notes.c to notes-utils.c

[Andreas Krey]

On Wed, 12 Jun 2013 13:28:05 +, Felipe Contreras wrote:
...
 And you are
 doing that with the express purpose of annoying.

Where did 'assume good faith' go to today?

Andreas

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

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

[Andreas Krey]

Some people run inetds that collect stderr of the spawned programs.
Give them 'git-daemon --inetd --no-syslog' to keep error output
on stderr.

Signed-off-by: Andreas Krey a.k...@gmx.de
---
 Documentation/git-daemon.txt |  4 
 daemon.c | 14 +++---
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 223f731..007d3fc 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -113,6 +113,10 @@ OPTIONS
Log to syslog instead of stderr. Note that this option does not imply
--verbose, thus by default only error conditions will be logged.
 
+--no-syslog::
+   Disable the implicit --syslog of --inetd and --deatch, thus keeping
+   error output on stderr.
+
 --user-path::
 --user-path=path::
Allow {tilde}user notation to be used in requests.  When
diff --git a/daemon.c b/daemon.c
index 6aeddcb..2f5d5bf 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1196,7 +1196,6 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, --inetd)) {
inetd_mode = 1;
-   log_syslog = 1;
continue;
}
if (!strcmp(arg, --verbose)) {
@@ -1207,6 +1206,10 @@ int main(int argc, char **argv)
log_syslog = 1;
continue;
}
+   if (!strcmp(arg, --no-syslog)) {
+   log_syslog = -1;
+   continue;
+   }
if (!strcmp(arg, --export-all)) {
export_all_trees = 1;
continue;
@@ -1263,7 +1266,6 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, --detach)) {
detach = 1;
-   log_syslog = 1;
continue;
}
if (!prefixcmp(arg, --user=)) {
@@ -1309,6 +1311,12 @@ int main(int argc, char **argv)
usage(daemon_usage);
}
 
+   if ((inetd_mode || detach)  log_syslog == 0)
+   log_syslog = 1;
+
+   if (log_syslog == -1)
+   log_syslog = 0;
+
if (log_syslog) {
openlog(git-daemon, LOG_PID, LOG_DAEMON);
set_die_routine(daemon_die);
@@ -1337,7 +1345,7 @@ int main(int argc, char **argv)
die(base-path '%s' does not exist or is not a directory,
base_path);
 
-   if (inetd_mode) {
+   if (inetd_mode  log_syslog) {
if (!freopen(/dev/null, w, stderr))
die_errno(failed to redirect stderr to /dev/null);
}
-- 
1.8.3.1.485.g9704416.dirty

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

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

[Andreas Krey]

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

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

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

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

Andreas

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

Re: Like commit -a, but...

[Andreas Krey]

On Mon, 05 Nov 2012 21:29:48 +, Andreas Krey wrote:
...
 But still I'd like to know if there is a cleaner solution,
 esp. with respect to the index.

Actually, it seems

 commit -m 'index'
 commit -a -m 'worktree'
 ...push
 git reset HEAD^
 git reset --soft HEAD^

might do the index trick.

But is there a direct way to convert the current working tree into a
tree object?

Andreas

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

Like commit -a, but...

[Andreas Krey]

Hi all,

I have a workflow for which I can't quite find the git tooling.

Essentially what I want is like 'git commit -a', except that I
want the resulting commit on a branch I name instead of the current
one, and I want my current index not being modified. At the moment
I emulate that via

  git commit -a -m TEMP: `date` $*  \
  git push -f nsd master:temp  \
  git reset HEAD^  \

but that a) changes the index (ok, not that bad), and it
will change my current commit in the case that there are
no unmodified files (no commit - head doesn't point
where I want). Ok, that can be prevented by --allow-empty.

But still I'd like to know if there is a cleaner solution,
esp. with respect to the index.

(Ah, the point of all this is to take the exact current worktree and
push it to a compiledeploy server; I don't want to chop my work into
commits before I even could compile it.)

Andreas



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

Re: Fwd: git cvsimport implications

[Andreas Krey]

On Fri, 17 May 2013 15:14:58 +, Michael Haggerty wrote:
...
 We both know that the CVS history omits important data, and that the
 history is mutable, etc.  So there are lots of hypothetical histories
 that do not contradict CVS.  But some things are recorded unambiguously
 in the CVS history, like
 
 * The contents at any tag or the tip of any branch (i.e., what is in the
 working tree when you check it out).

Except that the tags/branches may be made in a way that can't
be mapped onto any commit/point of history otherwise exported,
with branches that are done on parts of the trees first, or
likewise tags.

...
 That being said, I appreciate that cvsimport can do incremental imports.
  cvs2git doesn't even attempt it.  I've thought about what it would take
 to implement correct incremental imports in cvs2svn/cvs2git, and it is

Do these two produce stable output? That is, return the same commits
for multiple runs on the same repo?

Andreas

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

Re: [PATCH v2 00/14] Officially start moving to the term 'staging area'

[Andreas Krey]

On Thu, 24 Oct 2013 02:57:15 +, Karsten Blees wrote:
...
 The latter. I don't know about 'broader', but I'll try to summarize _my_ 
 world view:
 
 (1) Audience matters
 
 For actual users, we need an accurate model that supports a variety of use 
 cases without falling apart. IMO, a working model is more important than 
 simplicity. Finally, its more important to agree on the actual model than on 
 a vague term that can mean many things (theater stage vs. loading dock...).

Terms almost invariable mean multiple things in different contexts,
and assume new meaning in new fields.

 For potential users / decision makers, we need to describe git's features in 
 unmistakable terms that don't need extra explanation. In this sense, the 
 index / cache / staging area is not a feature in itself but facilitates a 
 variaty of broader features:
 - fine grained commit control (via index (add -i), but also commit -p, commit 
 --amend, cherry-pick, rebase etc.)

The audience will have a hard time understanding what these features
actually do (and how they interact) if we hide the underlying model from
them - they then need to build that model themselves.

And no decision-maker will make the effort to understand either the
operations you mention or the concept of the staging area, unless they
are also users.

...
 An index, as in a library, maps almost perfectly to what the git index is 
 _and_ what we do with it.

No, it doesn't. The git index actually contains the content of the added
files, not just an identity reference. (Unless, maybe, you consider file
sha1s as a reference and not actual content.) The point is that the
index doesn't just contain a mapping from file names to some objects,
but de facto a tree - that will form the next commit.

...
 (3a) Staging area (logistics)
 
 A staging area, as in (military) logistics / transportation, is about moving 
 physical goods around. You move an item from your stock to the staging area, 
 then onto the truck and finally deliver it to the customer.
 
 The defining characteristic of a physical good is its physical existence. 
 Each item is uniquely identifiable by a serial number.

Please show me the serial numbers on bullets.

 Problem #1: If an item in the staging area is broken, you fix it directly in 
 the staging area, because that's where it _is_.

That may be true in a physical world, and may not be - you can as well
replace them instead of repairing them in place.

The real problem: You can find some reason why any possible existing
name for this concept isn't correct.

...
 I don't see how a stage (as in a theater) is in any way related to the git 
 index.

It's because the name 'stage (noun)' goes with the verb 'stage'. You
stage a play, or you stage content to be committed. From that, you
may almost call the index just 'stage'.

Andreas

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

Re: Command-line git Vs IDE+plugin?

[Andreas Krey]

On Mon, 18 Nov 2013 18:11:54 +, Matthieu Moy wrote:
...
 I was wondering whether others had similar (or not) experience.

Similar. When I used eclipse I didn't even try to use the plugins
and just stayed on the command line. (Well, almost, but back then
jgit couldn't deal with submodules which I needed.)

I have the same experience with the few git GUIs I tried - none
stuck to me. Even 'git gut' hardly made the cut, I stay with
the command line except for gitk which is very useful to see
what you've done.

For people that live in the IDE anyway the mileage will vary,
but for me there is always some extra mismatch to overcode -
I know what the CLI is doing and think in terms of these
operations, and I'd need to understand what the GUI is thinkig
to be good for me (i.e. how operations are implemented there);
for me it always fells like a mist over the repo.

And I know that I'm missing on some features - the integration of history
examination into codebrowsing schoould be a good thing.

Still, if you show them eclipse, I'd also show them the git integration
in there. I dread the moment I have to show someone how to merge a pull
(or any merge) in eclipse though. :-(

Andreas

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

Re: I have end-of-lifed cvsps

[Andreas Krey]

On Thu, 12 Dec 2013 08:42:25 +, Martin Langhoff wrote:
...
  - run a cvs to git import at time T, resulting in repo G
  - make commits to cvs repo
  - run cvs to git import at time T1, pointed to G, and the import tool
 will only add the new commits found in cvs between T and T1.

I'm pretty sure that being given only G the incremental approach wouldn't
work - some extra state would be required.

But anyway, the replacement question is a) how fast the cvs-fast-export is
and b) whether its output is stable, that is, if the cvs repo C yields
a git repo G, will then C with a few extra commits yield G' where every
commit in G (as identified by its SHA1) is also in G', and G' additionally
contains the new commits that were made to the CVS repo.

If that is the case you effectively have an incremental mode, except that
it's not quite as fast.

At least that would be good enough for us - we ended up running a
filter-branch on the resulting history, and that takes some time anyway.

...
 The cvsimport+cvsps combo does a reasonable (though imperfect) job on
 'flying fish' CVS histories _and that is what most projects evolved to
 use_. If other cvs import tools can handle crazy histories, hats off
 to them. But careful with knifing cvsps!

It won't magically disappear from your machine, and you have been warned. :-)

Andreas

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

diff.renameLimit biting/silently ignored in cherry-pick

[Andreas Krey]

Hi all,

we're running into a problem with the rename detection; we're
at num_src=27320 and num_create=46731, which means that 'matrix'
would still be enumerable in int32, but... well, I don't yet know
where exactly it refuses to perform rename detection. I've tried to
set needed_rename_limit to 2^31-2 at the place where it was set to the
maximum of num_src and num_create, but that doesn't help. Where could
I affect this?

Also we have the impression that 'git cherry-pick' silently stops
doing rename detection in this situation - it doesn't take nearly
long enough to perform it, and it clearly misses renames.

I'm trying to do a 'diff --name-status -M' to see whether the
rename is properly detected, but I guess the real way would
be to make cherry-pick still perform rename detection, and
to find out how to do *that*.

Cheers,

Andreas

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

BUG: 'error: invalid key: pager.show_ref' on 'git show_ref'

[Andreas Krey]

Hi all,

there seems to be a regression in the behaviour of 'git show_ref'
(note the underscore). In v2.0.3-711-g586f414 it starts to say:

  $ ./git show_ref
  error: invalid key: pager.show_ref
  git: 'show_ref' is not a git command. See 'git --help'.

and somewhere (probably two commits, judging the diffs)
later that changes again to:

  $ git show_ref
  error: invalid key: pager.show_ref
  error: invalid key: alias.show_ref
  git: 'show_ref' is not a git command. See 'git --help'.

Apparently we need to squelch this message from
within git_config_get_* in this case?

Still present in 2.3.0.

Andreas

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

Re: Regarding the determinacy of 'git describe'

[Andreas Krey]

On Fri, 16 Jan 2015 14:29:17 +, Andreas Krey wrote:
...
 === /tmp/tmp-ws-20150116-11355-v7zfcc
 
 searching to describe HEAD
  lightweight4 r2.4/bl-0
  lightweight4 r2.4/bl-1
 traversed 5 commits
 r2.4/bl-0-4-g689e350

Apparently, this comes because two of the commit have the same timestamp,
affecting the log ordering (and presumably the order in which they
are used by 'git describe' as well). Also explains why it happens with
different probability on different machines.

But should 'git describe' behave this way?

Andreas

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

Regarding the determinacy of 'git describe'

[Andreas Krey]

Hi all again,

today another expectation crumbled.

I expected the algo of 'git describe' to be deterministic,
but it happens to return different tags in structurally
identical repositories. These are generated on each run
of a test (and obviously have different dates and thus
commit IDs), and 'git describe' doesn't return the same
tags in all of them.

Is that expected behaviour?

The repos each look like
(commit id and parents truncated to three chars):

538 26d 8f5 (HEAD, origin/r2.4/feature-2, r2.4/feature-2) Merge branch 
'r2.4/master' into r2.4/feature-2
26d 20c feature: 1st part
8f5 ac6 (origin/r2.4/master, origin/HEAD, r2.4/master) main: 3rd 
commit
ac6 20c (tag: r2.4/bl-1) main: 2nd commit
20c (tag: r2.4/bl-0, origin/sidestep) module: initial

So HEAD is two hops away from both tags (bl-0 via 26d and bl-1 via 8f5),
but for one I'd hoped that it always pick bl-1, and especially I'd expect
it to be consistent for a given structure).

Andreas

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

Re: Regarding the determinacy of 'git describe'

[Andreas Krey]

To follow up on myself, this is the output of 'git describe --debug
--tags' and 'git log --oneline --decor --parents' for each of the
two repos.

The one irritating thing is that in two of them the inital commit is
not the bottommost in the log output.

To make my expectation more concrete: I would expect 'git describe'
to output the tag where the number of commits that are in HEAD but not
in the tag is the lowest, and that would (always) be the bl-1 here.


=== /tmp/tmp-ws-20150116-11061-169bt1w

searching to describe HEAD
 lightweight3 r2.4/bl-1
 lightweight4 r2.4/bl-0
traversed 5 commits
r2.4/bl-1-3-gd760b4b

d760b4b 6e15dfc d905814 (HEAD, origin/r2.4/feature-2, r2.4/feature-2) Merge 
branch 'r2.4/master' into r2.4/feature-2
6e15dfc ad4e371 feature: 1st part
d905814 86f7fcf (origin/r2.4/master, origin/HEAD, r2.4/master) main: 3rd commit
86f7fcf ad4e371 (tag: r2.4/bl-1) main: 2nd commit
ad4e371 (tag: r2.4/bl-0, origin/sidestep) module: initial

=== /tmp/tmp-ws-20150116-11355-v7zfcc

searching to describe HEAD
 lightweight4 r2.4/bl-0
 lightweight4 r2.4/bl-1
traversed 5 commits
r2.4/bl-0-4-g689e350

689e350 93d9eb5 d768596 (HEAD, origin/r2.4/feature-2, r2.4/feature-2) Merge 
branch 'r2.4/master' into r2.4/feature-2
93d9eb5 e17d86b feature: 1st part
d768596 6e35c9c (origin/r2.4/master, origin/HEAD, r2.4/master) main: 3rd commit
e17d86b (tag: r2.4/bl-0, origin/sidestep) module: initial
6e35c9c e17d86b (tag: r2.4/bl-1) main: 2nd commit

Andreas

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

Re: Big repo not shrinking on repack or gc?

[Andreas Krey]

On Wed, 14 Jan 2015 07:49:36 +, Jeff King wrote:
...
 You don't need the -f here. Just git repack -ad should be enough
 (and the -f probably makes it _way_ slower).

Indeed, factor four.

However, my expectation is that a repack -ad will remove all the
old pack files, as what is in there is either referenced and put
into the new pack, or dropped = there should be a single pack file
afterwards.

This is not the case. :-( (Done only with 1.8.2 due to
lack of compilers for this box.)

Andreas

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

Re: Big repo not shrinking on repack or gc?

[Andreas Krey]

On Thu, 15 Jan 2015 18:05:46 +, Bryan Turner wrote:
...
 No, Stash will only do that in a repository which has been forked. In
 any non-forked repository, Stash does not interact with garbage
 collection in any way. Auto GC is left enabled, and all pruning
 settings are left at their defaults. The default pruning interval is
 two weeks, so if your development approach is rebase-heavy you may
 need to adjust them.
 
 What are the contents of some of those .keep files? If they're written
 by Stash they contain a message saying so. (GENERATED BY ATLASSIAN
 STASH - DO NOT REMOVE)

They do. So it seems it was forked once upon a time, but...

/opt/apps/atlassian/stash-data/shared/data/repositories $ grep '' 
*/objects/info/alternates
158/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/20/objects
45/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/33/objects
93/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/91/objects

...there is no trace of a fork still existing (the repo in question is 143).

Andreas

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

Re: Big repo not shrinking on repack or gc?

[Andreas Krey]

On Thu, 15 Jan 2015 12:23:00 +, Bryan Turner wrote:
...
  Guess in the dark: ls -l .git/objects/pack
  Do you see any .keep files?

Lots of. :-(

 I'm one of the Stash developers and just noticed this thread. If the
 repository in question has been forked via Stash there likely _will_
 be .keep files. Stash uses alternates for forks, so it's possible, by
 deleting those kept packs and pruning objects (which you've already
 done I see) that you will corrupt, or have already corrupted, some
 number of the forks.

There are a few forks in this stash instance, but the repository in
question is neither the source nor the destination of any.

So, git seems to be mostly out of the equation now (gc and repack
apparently doing what they are supposed to do), and the question
moves to 'how can stash let such a repo grow to that size'.


 (At the moment Stash packs garbage into a dead
 pack which it flags with a .keep, to ensure forks don't lose access
 to objects that once existed upstream that they still reference.)

Does it do so in any case even if there is no actual fork? That would
explain a lot - we are daily (force-)pushing new commit in there (and
potentially big ones) that become garbage the next day, and should
be cleaned up rather fast.

(We're pulling them into another non-stash repo for longer-term keeping -
these are backups of dev repos in the form of git stash commits including
untracked files.)

Andreas

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

Re: Big repo not shrinking on repack or gc?

[Andreas Krey]

On Wed, 14 Jan 2015 15:39:46 +, Andreas Krey wrote:
...
 This is not the case. :-( (Done only with 1.8.2 due to
 lack of compilers for this box.)

Neither for current git (copied repo to other machine)
There is one new pack file of a plausible size (25G),
and 65G worth of old packfiles.

Andreas

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

Re: Big repo not shrinking on repack or gc?

[Andreas Krey]

On Wed, 14 Jan 2015 07:49:36 +, Jeff King wrote:
 On Wed, Jan 14, 2015 at 12:51:30PM +0100, Andreas Krey wrote:
 
  I have a repo here that is 130G, but when I clone --mirror it, the result
  is only 25G big.  Because of the --mirror I don't think that I missed
  any refs that keep objects only in the source repo.
 
 Perhaps some objects are mentioned by reflogs, but not by the refs? They
 would not be transferred as part of a clone. Try:
 
   git rev-list --objects --all | cut -d' ' -f1 | sort reachable
   git rev-list --objects --reflog | cut -d' ' -f1 | sort reflogs

Actually, the output of 'git rev-list --objects --reflog' is empty, and
there isn't even a reflog (or similar) directory. (This is a bare repo
inside atlass. stash.)

...
  I already tried 'git repack -fad' and 'git gc' to shrink the original repo,
 
 You don't need the -f here. Just git repack -ad should be enough
 (and the -f probably makes it _way_ slower).

Right, the -f is an old workaround for old jgits in another repo.

Apparently, part of the trick is --prune=all or similar on 'git gc',
to get rid of the loose objects faster. That got a copy of the repo
down to around 70G - still way to go.

Andreas

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

Big repo not shrinking on repack or gc?

[Andreas Krey]

Hi everybody,

I have a repo here that is 130G, but when I clone --mirror it, the result
is only 25G big.  Because of the --mirror I don't think that I missed
any refs that keep objects only in the source repo.

I already tried 'git repack -fad' and 'git gc' to shrink the original repo,
but it only shaved off 3G, and there are a lot of loose objects and old
pack files that I simply don't expect to be there after a repack.

Shouldn't 'git gc' (even without --aggressive) or a 'repack -fad' remove
those redundant objects and packs?

How to clean this up? (Additional problem: I don't have enough space
to run a repack anymore.)

Andreas

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

[PATCH] refs.c: get_ref_cache: use a bucket hash

[Andreas Krey]

get_ref_cache used a linear list, which obviously is O(n^2).
Use a fixed bucket hash which just takes a factor of 10
(~ 317^2) out of the n^2 - which is enough.

Signed-off-by: Andreas Krey a.k...@gmx.de
---

This brings 'git clean -ndx' times down from 17 minutes
to 11 seconds on one of our workspaces (which accumulated
a lot of ignored directories). Actuallly using adaptive
hashing or other structures seems overkill.

 refs.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/refs.c b/refs.c
index e23542b..8198d9e 100644
--- a/refs.c
+++ b/refs.c
@@ -982,6 +982,8 @@ struct packed_ref_cache {
struct stat_validity validity;
 };
 
+#define REF_CACHE_HASH 317
+
 /*
  * Future: need to be in struct repository
  * when doing a full libification.
@@ -996,7 +998,7 @@ static struct ref_cache {
 * is initialized correctly.
 */
char name[1];
-} ref_cache, *submodule_ref_caches;
+} ref_cache, *submodule_ref_caches[REF_CACHE_HASH];
 
 /* Lock used for the main packed-refs file: */
 static struct lock_file packlock;
@@ -1065,18 +1067,19 @@ static struct ref_cache *create_ref_cache(const char 
*submodule)
  */
 static struct ref_cache *get_ref_cache(const char *submodule)
 {
-   struct ref_cache *refs;
+   struct ref_cache *refs, **bucketp;
+   bucketp = submodule_ref_caches + strhash(submodule) % REF_CACHE_HASH;
 
if (!submodule || !*submodule)
return ref_cache;
 
-   for (refs = submodule_ref_caches; refs; refs = refs-next)
+   for (refs = *bucketp; refs; refs = refs-next)
if (!strcmp(submodule, refs-name))
return refs;
 
refs = create_ref_cache(submodule);
-   refs-next = submodule_ref_caches;
-   submodule_ref_caches = refs;
+   refs-next = *bucketp;
+   *bucketp = refs;
return refs;
 }
 
-- 
2.3.2.223.g7a9409c
--
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] refs.c: get_ref_cache: use a bucket hash

[Andreas Krey]

On Mon, 16 Mar 2015 10:23:05 +, Junio C Hamano wrote:
 Andreas Krey a.k...@gmx.de writes:
 
...
 say a lot of ignored directories, but do you mean directories in
 the working tree (which I suppose do not have much to do with the
 submodule_ref_caches[])?

Apparently, they do.

I am guessing that the repository has tons
 of submodules?

Not a single one. Thats's thie interesting thing that
makes me think I'm not actually solving the right problem.

This repo has about 100k subdirectories that are ignored
(I don't know whether directly or within ignored dirs),
and strace said that git looks for '.git/HEAD' and one
other file in each of these. Apparently it trieds to
find out if any of these dirs happen to be a git repo
which git clean treats specially, but it seems it also
calls get_ref_cache for each of these dires even though
the turn out not to be a sub-repo.

In other words: I suspect that get_ref_cache shouldn't
be called that often, or that the cache entries should
be removed once a directory is found not to be a sub repo.
Then the linear list wouldn't really hurt.

I'll look into that tomorrow, and also into the hashmap API.

Andreas

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

Re: git's directory is _prepended_ to PATH when called with an absolute path

[Andreas Krey]

On Wed, 22 Apr 2015 08:36:00 +, David Rodríguez wrote:
...
 * User is relying on a custom path to select their Ruby version. For 
 example, let's say the first folder in path is ~/.rubies/2.2.2/bin.
 * User runs /usr/bin/git commit and a pre-commit hook is triggered.
 * The pre-commit hook starts with #!/us/bin/env ruby to select the 
 Ruby to be used in the hook,

Yes...but shouldn't the hook itself know which ruby version it needs?

After all, if I go into that directory with another ruby setup in my
PATH, the hook should still work, and presumably that requires that
the hook itself selects its version, and not the user's context.

Andreas

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

Re: git's directory is _prepended_ to PATH when called with an absolute path

[Andreas Krey]

On Tue, 21 Apr 2015 18:37:29 +, David Rodríguez wrote:
...
 This causes issues with Ruby git hooks, because Ruby version managers 
 rely on custom settings in PATH to select the Ruby executable,

Even if git wouldn't modify PATH this is still a broken way to do that.
What ruby to execute a hook with is a property of the hook, not of the
user context invoking it.

Andreas

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

Re: support git+mosh for unreliable connections

[Andreas Krey]

On Wed, 15 Apr 2015 21:25:44 +, Dennis Kaarsemaker wrote:
...
 It does not and cannot work. The way mosh works, is that it uses ssh to
 log in and launch a mosh-server daemon. This daemon and the mosh client
 then communicate via a custom UDP protocol. The SSH connection is closed
 after the mosh-server has been launched as it is no longer needed.
 
 The communication between the mosh client and server synchronizes
 terminal state, somewhat like what screen/tmux do.

I object to the 'can not' part a bit. There is (1) the terminal state
prediction and (2) the reliable-over-reconnects communication, and for
a noninteractive usage you'd need only (2).

Once upon a time I implemented a simple UDP server and client;
the client to be used as a ProxyCommand in ssh, and the server
just talks to the local ssh server. This pretty much does what
the OP wants, and it works just as a transport for ssh, so
all ssh features are there (but of course there is no
terminal prediction). Unfortunately it needs to be ported
to libev/libuv before it could be released. It's *much*
simpler than mosh, although the use-ssh-to-start-server
trick would be nice.)

Andreas

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

Re: [PATCH] refs.c: get_ref_cache: use a bucket hash

[Andreas Krey]

On Tue, 17 Mar 2015 01:48:00 +, Jeff King wrote:
> On Mon, Mar 16, 2015 at 10:35:18PM -0700, Junio C Hamano wrote:
> 
> > > It looks like we don't even really care about the value of HEAD. We just
> > > want to know "is it a git directory?". I think in other places (like
> > > "git add"), we just do an existence check for "$dir/.git". That would
> > > not catch a bare repository, but I do not think the current check does
> > > either (it is looking for submodules, which always have a .git).
> > 
> > If we wanted to be consistent, perhaps we should be reusing the "is
> > this a git repository?" check used by the auto-discovery codepath
> > (setup.c:is_git_directory(), perhaps?), but the idea looks simple
> > enough and sounds sensible.
> 
> Yeah, I almost suggested that, but I'm concerned that would make us
> inconsistent with how we report untracked files. I thought that dir.c
> used ".git" as a magic token there.
> 
> But it seems I'm wrong. We do ignore ".git" directly in treat_path(),
> but treat_directory actually checks resolve_gitlink_ref. I think this
> will suffer the same problem as Andreas's original issue (e.g., if you
> run "git ls-files -o").

Guess what landed on my desk this week. Same repo, same
application test suite, same problem, now with 'git ls-files -o'.

> Likewise, I think dir.c:remove_dir_recurse is in a similar boat.
> Grepping for resolve_gitlink_ref, it looks like there may be others,
> too.

Can't we handle this in resolve_gitlink_ref itself? As I understand it,
it should resolve a ref (here "HEAD") when path points to a submodule.
When there isn't one it should return -1, so:

diff --git a/refs.c b/refs.c
index 132eff5..f8648c5 100644
--- a/refs.c
+++ b/refs.c
@@ -1553,6 +1553,10 @@ int resolve_gitlink_ref(const char *path, const char 
*refname, unsigned char *sh
if (!len)
return -1;
submodule = xstrndup(path, len);
+   if (!is_git_directory(submodule)) {
+   free(submodule);
+   return -1;
+   }
refs = get_ref_cache(submodule);
free(submodule);

I'm way too little into the code to see what may this may get wrong.

But this, as well as the old hash-ref-cache patch speeds me
up considerably, in this case a git ls-files -o from half a
minute of mostly user CPU to a second.

> All of these should be using the same test, I think. Doing that with
> is_git_directory() is probably OK. It is a little more expensive than we
> might want for mass-use (it actually opens and parses the HEAD file in
> each directory),

This happens as well when we let resolve_gitlink_ref run its old course.
(It (ls-files) even seems to try to open .git and then .git/HEAD, even
if the former fails with ENOENT.)

Andreas

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

[RFC] rename detection: allow more renames

[Andreas Krey]

Hi all,

we also ran into the maximum rename limit
in the rename detection. (Yes, we get a lot
of rename candidates when cherry-picking
between two specific releases.)

The code talks about limiting the size
of the rename matrix, but as far as I
can see, the matrix itself never exists
as such, and the only thing that could
actually overflow is the computation
for the progress indication. This
can be fixed by reporting just the
destinations checked instead of the
combinations, since we only update
the progress once per destination
anyway.

If the direction is good, I will
shape it up (and obtain the
proper signoffs).


diff --git a/diffcore-rename.c b/diffcore-rename.c
index 749a35d..279f24e 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -368,7 +368,7 @@ static int too_many_rename_candidates(int num_create,
int rename_limit = options->rename_limit;
int num_src = rename_src_nr;
int i;
-
+   static int max_rename_limit = 10;
options->needed_rename_limit = 0;
 
/*
@@ -380,8 +380,8 @@ static int too_many_rename_candidates(int num_create,
 * but handles the potential overflow case specially (and we
 * assume at least 32-bit integers)
 */
-   if (rename_limit <= 0 || rename_limit > 32767)
-   rename_limit = 32767;
+   if (rename_limit <= 0 || rename_limit > max_rename_limit)
+   rename_limit = max_rename_limit;
if ((num_create <= rename_limit || num_src <= rename_limit) &&
(num_create * num_src <= rename_limit * rename_limit))
return 0;
@@ -515,7 +515,7 @@ void diffcore_rename(struct diff_options *options)
if (options->show_rename_progress) {
progress = start_progress_delay(
_("Performing inexact rename detection"),
-   rename_dst_nr * rename_src_nr, 50, 1);
+   rename_dst_nr, 50, 1);
}
 
mx = xcalloc(num_create * NUM_CANDIDATE_PER_DST, sizeof(*mx));
@@ -552,7 +552,7 @@ void diffcore_rename(struct diff_options *options)
diff_free_filespec_blob(two);
}
dst_cnt++;
-   display_progress(progress, (i+1)*rename_src_nr);
+   display_progress(progress, (i+1));
}
stop_progress();


And we would also like to see progress when doing
a cherry pick - in our case this takes a few minutes:

 
diff --git a/sequencer.c b/sequencer.c
index 3c060e0..8fce028 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -282,6 +282,7 @@ static int do_recursive_merge(struct commit *base, struct 
commit *next,
 
for (xopt = opts->xopts; xopt != opts->xopts + opts->xopts_nr; xopt++)
parse_merge_opt(, *xopt);
+   o.show_rename_progress = isatty(2);
 
clean = merge_trees(,
head_tree,


Andreas

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

Re: [PATCH] refs.c: get_ref_cache: use a bucket hash

[Andreas Krey]

On Fri, 13 Nov 2015 19:01:18 +, Jeff King wrote:

> > Can't we handle this in resolve_gitlink_ref itself? As I understand it,
> > it should resolve a ref (here "HEAD") when path points to a submodule.
> > When there isn't one it should return -1, so:
> 
> I'm not sure. I think part of the change to git-clean was that
> is_git_directory() is a _better_ check than "can we resolve HEAD?"
> because it covers empty repos, too.

I could do

  refs = find_ref_cache(submodule);
  if (!refs && !is_git_directory(

in resolve_gitlink_ref().

...
> > @@ -1553,6 +1553,10 @@ int resolve_gitlink_ref(const char *path, const char 
> > *refname, unsigned char *sh
> > if (!len)
> > return -1;
> > submodule = xstrndup(path, len);
> > +   if (!is_git_directory(submodule)) {
> > +   free(submodule);
> > +   return -1;
> > +   }
> > refs = get_ref_cache(submodule);
> > free(submodule);
> 
> I don't think it produces wrong outcomes, but I think it's sub-optimal.
> In cases where we already have a ref cache, we'll hit the filesystem for
> each lookup to re-confirm what we already know. That doesn't affect your
> case, but it does when we actually _do_ have a submodule.

I could do

  refs = find_ref_cache(submodule);
  if (!refs && !is_git_directory(

Also, in my case the current code tries .git/HEAD and .git/packed-refs
for each directory.

> So if we were to follow this route, I think it would go better in
> get_ref_cache itself (right after we determine there is no existing
> cache, but before we call create_ref_cache()).

The stupid part is that get_ref_cache itself only creates the
cache entry and leaved the actual check for later - then it
is too late to not create the cache entry.

Also, when we put it into get_ref_cache we need to return null
for our case and see what for_each_ref_submodule & co make out of that.
That's why I'd like it in resolve_gitlink_ref. :-) Or we put an
no_create parameter into get_ref_cache(). Probably violating
some style guide:

diff --git a/refs.c b/refs.c
index 132eff5..005d0eb 100644
--- a/refs.c
+++ b/refs.c
@@ -1160,7 +1160,7 @@ static struct ref_cache *create_ref_cache(const char 
*submodule)
  * will be allocated and initialized but not necessarily populated; it
  * should not be freed.
  */
-static struct ref_cache *get_ref_cache(const char *submodule)
+static struct ref_cache *get_ref_cache(const char *submodule, int do_create)
 {
struct ref_cache *refs;
 
@@ -1171,6 +1171,9 @@ static struct ref_cache *get_ref_cache(const char 
*submodule)
if (!strcmp(submodule, refs->name))
return refs;
 
+   if (!do_create && !is_git_directory(submodule))
+   return 0;
+
refs = create_ref_cache(submodule);
refs->next = submodule_ref_caches;
submodule_ref_caches = refs;
@@ -1553,9 +1556,12 @@ int resolve_gitlink_ref(const char *path, const char 
*refname, unsigned char *sh
if (!len)
return -1;
submodule = xstrndup(path, len);
-   refs = get_ref_cache(submodule);
+   refs = get_ref_cache(submodule, 0);
free(submodule);
 
+   if (!refs)
+   return -1;
+
retval = resolve_gitlink_ref_recursive(refs, refname, sha1, 0);
return retval;
 }
@@ -2126,7 +2132,7 @@ int for_each_ref(each_ref_fn fn, void *cb_data)
 
 int for_each_ref_submodule(const char *submodule, each_ref_fn fn, void 
*cb_data)
 {
-   return do_for_each_ref(get_ref_cache(submodule), "", fn, 0, 0, cb_data);
+   return do_for_each_ref(get_ref_cache(submodule, 1), "", fn, 0, 0, 
cb_data);
 }
 
 int for_each_ref_in(const char *prefix, each_ref_fn fn, void *cb_data)
@@ -2146,7 +2152,7 @@ int for_each_fullref_in(const char *prefix, each_ref_fn 
fn, void *cb_data, unsig
 int for_each_ref_in_submodule(const char *submodule, const char *prefix,
each_ref_fn fn, void *cb_data)
 {
-   return do_for_each_ref(get_ref_cache(submodule), prefix, fn, 
strlen(prefix), 0, cb_data);
+   return do_for_each_ref(get_ref_cache(submodule, 1), prefix, fn, 
strlen(prefix), 0, cb_data);
 }
 
 int for_each_tag_ref(each_ref_fn fn, void *cb_data)

(might be nicer to split into find_ref_cache() and get_ref_cache()
instead of adding the parameter).

...
>   2. But for a little more work, pushing the is_git_directory() check
>  out to the call-sites gives us probably saner semantics overall.

Actually, I don't quite think that. The code we push out would be
the same in each place ('is_git_directory() && ...'), wouldn't it?

Andreas

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

Re: [PATCH] refs.c: get_ref_cache: use a bucket hash

[Andreas Krey]

On Fri, 13 Nov 2015 19:01:18 +, Jeff King wrote:
...
>   2. But for a little more work, pushing the is_git_directory() check
>  out to the call-sites gives us probably saner semantics overall.

Oops, now I get it[1]: You mean replacing resolve_gitlink_ref usages
with is_git_directory, like:

diff --git a/dir.c b/dir.c
index d2a8f06..7765dc6 100644
--- a/dir.c
+++ b/dir.c
@@ -1375,8 +1375,7 @@ static enum path_treatment treat_directory(struct 
dir_struct *dir,
if (dir->flags & DIR_SHOW_OTHER_DIRECTORIES)
break;
if (!(dir->flags & DIR_NO_GITLINKS)) {
-   unsigned char sha1[20];
-   if (resolve_gitlink_ref(dirname, "HEAD", sha1) == 0)
+   if (is_git_directory(dirname))
return path_untracked;
}
return path_recurse;

That, I like. If it is correct.

Andreas

[1] After reading the introduction of is_git_directory, 0179ca7a62.

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

git gc/prune runs again and again

[Andreas Krey]

Hi all,

I have a bit of an annoying behaviour in git gc;
there is a repo I regularly do a fetch in, and
this kicks off a gc/prune every time. I remember
there being a heuristic with being that many files
in .git/objects/17 as the gc trigger.

Which is unfortunate if the gc does not actually
reduce the number of files there because they
aren't old enough => gc comes right back.

What can I do there? (This git is a bit old, 2.2.2)

Andreas


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

Re: git gc/prune runs again and again

[Andreas Krey]

On Tue, 03 Nov 2015 16:01:24 +, Duy Nguyen wrote:

> > I have a bit of an annoying behaviour in git gc;
> > there is a repo I regularly do a fetch in, and
> > this kicks off a gc/prune every time. I remember
> > there being a heuristic with being that many files
> > in .git/objects/17 as the gc trigger.

(It might be a good idea to use a random slot here.)

...
> > What can I do there? (This git is a bit old, 2.2.2)
> 
> Run "git prune". 2.2.2 hides this suggestion to run git-prune in this
> case. The next git version will show it back.

Actually, there is a 'git prune --expire 2.weeks.ago --no-progress'
running under the 'git gc --auto --quiet', and I don't want to drop
the expiry time lightly.

Andreas

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

Re: git clean performance issues

[Andreas Krey]

On Sat, 04 Apr 2015 15:55:07 +, Jeff King wrote:
...
> I think this is the same issue that was discussed here:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/265560/focus&5585
> 
> There is some discussion of a possible fix in that thread. I was hoping
> that Andreas was going to look further and produce a patch, but I
> imagine he got busy with other things.

That about sums it up. However I now have a similar issue;
git ls-files shows the same behaviour (takes relatively
forever at 100% CPU), and runs instantly with my patch
from back then. Nothing seems to have changed, so I
may have another chance to look into this.

Andreas

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

best practices against long git rebase times?

[Andreas Krey]

Hi all,

our workflow is pretty rebase-free for diverse reasons yet.

One obstacle now appearing is that rebases simply take
very long - once you might want to do a rebase there are
several hundred commits on the remote branch, and our tree
isn't small either.

This produces rebase times in the minute range.
I suppose this is because rebase tries to see
if there are new commits in the destination
branch that are identical to one of the local
commits, to be able to skip them. (I didn't
try to verify this hypothesis.)

What can we do to make this faster?

Andreas

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

Re: best practices against long git rebase times?

[Andreas Krey]

On Fri, 04 Dec 2015 15:31:03 +, John Keeping wrote:
...
> I'm pretty sure that you're right and the cherry-pick analysis is where
> the time is spent.

But I'm pretty surprised as to the amount of CPU time that goes there.

I'm now rebasing a single commit with a single blank line added,
and for 3000 new commits to rebase over (with 64 MByte of git log -
for them) it takes twelve minutes, or about for commits per second,
and all user CPU, no I/O. It's pretty linear in number of commits, too.

Andreas

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

Re: [PATCH/RFC 3/3] ls-files/dir: use is_git_repo to detect submodules

[Andreas Krey]

On Sat, 05 Dec 2015 02:37:44 +, Jeff King wrote:
...
> Hrm. Weird. You'd think it would break with the existing code if I do
> this, then:
> 
...
> - (cd a/b/c; git init) &&
> + (cd a/b/c; git init && git commit --allow-empty -m foo) &&
>   git config remote.origin.url ../foo/bar.git &&
>   git submodule add ../bar/a/b/c ./a/b/c &&

I tried a -f here instead; did not work either.

I guess I will first wade through the other failures my 'fix'
causes to see the total damage.

...
> We know it is a git dir, but there is no sha1 for us to actually add as
> the gitlink entry.
> 
> If that is the case, then there is either some very tricky refactoring
> required,

Yes, it looks like the return code delivered need to be slightly different
dependent on the user.

> or what we are trying to do here is simply wrong. Maybe it
> would be simpler to just speed up resolve_gitlink_ref with a better data
> structure.

Which is what I did on square one, but now we already have a real fix
for git clean, and now it's even less advantageous the fix the consequence
(the submodule cache blowing up) instead of the cause (asking for it
in the first place).

I don't think we should let is_git_repository look for a valid(ish) HEAD.

Andreas

PS: I seem to not quite have send-email under control, the envelope from
seems to made the patches not reach the mailing list (nor me in the CC).

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

Re: best practices against long git rebase times?

[Andreas Krey]

On Fri, 04 Dec 2015 18:09:33 +, demerphq wrote:
...
> I bet you have a lot of refs; tags, or branches.

We do, but removing them doesn't noticably change the times
(12k refs vs. 120, mostly tags). I'm just running the
second series, the first (with many refs) ended
with rebasing over 3000 commits, for which git log -p
outputs 64 MByte, and the rebase takes 12 minutes.

Andreas

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

Re: [RFC] rename detection: allow more renames

[Andreas Krey]

Hi Jeff,

thanks for the reply!

On Tue, 24 Nov 2015 18:33:28 +, Jeff King wrote:
...
> I didn't dig in the archive, but I think we discussed the "just show
> progress for destinations" before. The problem you run into is that the
> items aren't a good indication of the amount of work. You really are
> doing n*m work, so if you just count "m", it can be very misleading if
> "n" is high (and vice versa).

True, but the loops do progress indication for destinations only anyway.
So if you only have three destinations and a zillion sources, you
will still get only three progress updates, even if they say
'one zillion (33%)', 'two zillion (67%)', ...

I think as long as this is the case we can as well report the destination
count; maybe put the source count somewhere in the progress text.

> Might it make more sense just to move to a larger integer size?

Which would be? I'd venture into the progress code to identify
the necessary changes.

> Or
> perhaps to allow a higher limit for each side as long as the product of
> the sides does not overflow?

We're somewhat close to getting there. The rename detection runs
for several minutes in our cases.

Andreas

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

'untracked working tree files would be overwritten by merge' on ignored files?

[Andreas Krey]

Hi all,

when I have an ignored file in my workspace, is git
then also assumed not to remove it in the course
of a merge?

Shouldn't it then say that the file is ignored,
as it does not show up in the untracked section
of git status?

Regards, Andreas

PS: Test script (will remove anything named 'tst'):
rm -rf tst
mkdir tst
cd tst || exit 1
git init
echo '*.txt' >.gitignore
git add .
git commit -m initial
git checkout -b side
git checkout -
date >a.txt
git add -f a.txt
git commit -m 'new file'
git checkout side
git commit -m 'nix' --allow-empty
touch a.txt
git status --ignored# Shows a.txt as ignored
git merge master# Will complain
git version

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

Re: 'untracked working tree files would be overwritten by merge' on ignored files?

[Andreas Krey]

On Tue, 14 Jun 2016 10:06:16 +, Junio C Hamano wrote:
...
> 
> IIRC, untracked files are kept during merge and across checking out
> another branch.  Files that are deliberately marked as ignored by
> listing them to .gitignore mechanism are considered expendable, and
> they will be removed as necessary.

Apparently not. Waitaminute - I can check out the other branch,
and then the ignored file is replaced by the versioned file there,
as you say.

But when I try to merge the other branch, merge complains as in $subject.

That is, 'git merge other' does not work, but 'git checkout out;
git checkout -; git merge other' works because then the ignored file is
removed in the first checkout and no longer in the way for the merge:

$ git status --ignored
On branch side
Ignored files:
  (use "git add -f ..." to include in what will be committed)

a.txt

nothing to commit, working directory clean
$ git merge master
error: The following untracked working tree files would be overwritten by 
merge:
a.txt
Please move or remove them before you can merge.
Aborting
$ git checkout master
Switched to branch 'master'
$ git checkout -
Switched to branch 'side'
$ git merge master
Merge made by the 'recursive' strategy.
 a.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 a.txt
$

Andreas

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

Code review tool recommendations - replacement for crucible?

[Andreas Krey]

Hi all,

I'm looking for pointers to review tools that work with git (obviously),
and can deal sensibly with bigger reviews. Things we need:

- Ability to split (set of) commits into multiple reviews,
  so parts of changes can be reviewed by the respective owners
  (or assign different reviewers to different files/subtrees
  in a review).

- Tracking of files (or changes) already reviewed (due to the large numbers),
  and of the handling of issues found so far.

- Support incremental reviews, not just e.g. over the content of a
  pull request (bitbucket) When review comments are processed people
  want to be able to only review that change, and not to be forced
  to find that change in the entire previous changeset without
  the tool's support.

We were mostly content with atlassian crucible so far, but
it simply fails to index[1] our large product repo (5+ Gb) so
we switched to just give it diffs to review, and it fails
to properly display renames, and fails in a few minor
but annoying ways in dealing with these big reviews.

Any pointers?

- Andreas

[1] Crucible seems to be svn-centric, and the mapping
from git to svn changesets they use internally
apparently is O(n^{too much}) - just indexing
a new branch identical to an existing one takes
hours here.

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

Re: Code review tool recommendations - replacement for crucible?

[Andreas Krey]

On Thu, 16 Jun 2016 11:55:56 +, Richard Ipsum wrote:
...
> Have you considered Gerrit[1] already?
> It would seem to handle the cases you're interested in.

Possible, but only after a lot of user education.

We don't currently rewrite commits for review comments, and
neither can we get (all) people to create feature-oriented
commits, so we really need to review multiple commits in
one review, and assign reviewers to subtrees. We could do
that by repacking the changes into new commits, but that
would defeat the purpose.

Also, we often do reviews after feature integration,
and also do partial reviews long before a new
project is integrated.

In other words: Lots of impedance mismatch.

Andreas

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

'Failed to create .git/index.lock'

[Andreas Krey]

Hi all,

I have a single workspace where executing merges
occasionally leads to a left-over .git/index.lock file
that prevents me from adding resolved conflicted files.

I'm running a sped-up integration/feature branch process,
and the merges and conflict resolution are automated.
But the index.lock thing is happening only in one repo
of the three that are doing this.

Any hints as to debugging this?

(It is not a running background gc, the lock file
is still around when there is nothing running
any more, for hours.)

Andreas

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

Re: Minor bug, git ls-files -o aborts because of broken submodules

[Andreas Krey]

On Fri, 22 Jan 2016 17:26:50 +, Jeff King wrote:
...
> Here it is. I think this is the right fix, based on the previous attempt
> by Andreas and my comments. Sorry for stealing your topic,

This seems to keep happening with things I try to patch. :-)

> but I hope
> the perf numbers in the second patch will brighten your day. :)

The patches are 'quadratically' improving my case as well,
many thanks for completing this. (I was just mustering
the steam for another round of work on this.)

Andreas

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

Re: 'Failed to create .git/index.lock'

[Andreas Krey]

On Mon, 15 Feb 2016 18:06:33 +, Lars Schneider wrote:
> Hi Andreas,
> 
> I am looking into a similar issue with SourceTree on Windows right now. 
> However, in my case it only happens when I switch branches.

Semi-bingo. That is actually a difference between the workspace this
happens in and the others. This one works on many branches; the others
clone anew for each new branch.

I investigated the Git commands that SourceTree triggers and it looks like it 
is doing something like this:

> (1) Run checkout command
> git.exe --no-pager -c color.branch=false -c color.diff=false -c 
> color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false 
> checkout MY-BRANCH
> 
> (2) Run rev-parse command 
> git.exe --no-pager -c color.branch=false -c color.diff=false -c 
> color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false 
> rev-parse HEAD^1
> 
> My assumption is that SourceTree triggers these two commands in parallel and 
> sometimes (2) locks the repo first which makes (1) fail.

That would be partly a bug in SourceTree to do so.

> Does your Git process run on Windows, too?

No. RHEL7 Linux.

> Is there a possibility that you issue Git commands in parallel?

I don't think so, except for background GC (which isn't quite background -
one phase seems to still run foregrounded).

> I also have read that certain anti virus software can trigger these errors on 
> Windows.

That is an ugly problem indeed.

> I looked through the Git code found that increasing "core.packedrefstimeout" 
> [1] might help in some cases that trigger this error [2] but not in others 
> [3]. In my case this seems to help. Maybe it's worth a try for you, too?

I may need to look into that. Because sometimes the lock causes my
automatic process to fail but the lock file isn't there anymore when
I get to cleanup. But sometimes it keeps existing.

Andreas

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

git shortlog vs. stdin

[Andreas Krey]

Hi all,

I observed a strange an unexpected behaviour in 'git shortlog'.

When in git.git:

$ git shortlog -sn | wc
   14414493   31477

but with input redirected:

$ git shortlog -sn 
Date: Fri, 22 Jan 2010 07:29:21 -0800

[PATCH v2] commit: make --only --allow-empty work without paths

[Andreas Krey]

--only is implied when paths are present, and required
them unless --amend. But with --allow-empty it should
be allowed as well - it is the only way to create an
empty commit in the presence of staged changes.

Also remove the post-fact cleverness indication;
it's in the man page anyway.

Signed-off-by: Andreas Krey <a.k...@gmx.de>
---

Ok, I've removed the clever message, as Junio suggested.
I don't know what else to do to make it acceptable. :-)
We're going to deploy it internally anyway, but I think
it belongs in git.git as well (aka 'Can I has "will queue"?').

 Documentation/git-commit.txt | 3 ++-
 builtin/commit.c | 4 +---
 t/t7501-commit.sh| 9 +
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index f2ab0ee2e..4f8f20a36 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -265,7 +265,8 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
If this option is specified together with `--amend`, then
no paths need to be specified, which can be used to amend
the last commit without committing changes that have
-   already been staged.
+   already been staged. If used together with `--allow-empty`
+   paths are also not required, and an empty commit will be created.
 
 -u[]::
 --untracked-files[=]::
diff --git a/builtin/commit.c b/builtin/commit.c
index 8976c3d29..276c74034 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1206,10 +1206,8 @@ static int parse_and_validate_options(int argc, const 
char *argv[],
 
if (also + only + all + interactive > 1)
die(_("Only one of --include/--only/--all/--interactive/--patch 
can be used."));
-   if (argc == 0 && (also || (only && !amend)))
+   if (argc == 0 && (also || (only && !amend && !allow_empty)))
die(_("No paths with --include/--only does not make sense."));
-   if (argc == 0 && only && amend)
-   only_include_assumed = _("Clever... amending the last one with 
dirty index.");
if (argc > 0 && !also && !only)
only_include_assumed = _("Explicit paths specified without -i 
or -o; assuming --only paths...");
if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index d84897a67..0d8d89309 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -155,6 +155,15 @@ test_expect_success 'amend --only ignores staged contents' 
'
git diff --exit-code
 '
 
+test_expect_success 'allow-empty --only ignores staged contents' '
+   echo changed-again >file &&
+   git add file &&
+   git commit --allow-empty --only -m "empty" &&
+   git cat-file blob HEAD:file >file.actual &&
+   test_cmp file.expect file.actual &&
+   git diff --exit-code
+'
+
 test_expect_success 'set up editor' '
cat >editor <<-\EOF &&
#!/bin/sh
-- 
2.11.0.10.g1e1b186.dirty

Races on ref .lock files?

[Andreas Krey]

Hi all,

We're occasionally seeing a lot of 

  error: cannot lock ref 'stash-refs/pull-requests/18978/to': Unable to create 
'/opt/apps//repositories/68/stash-refs/pull-requests/18978/to.lock': File 
exists.

from the server side with fetches as well as pushes. (Bitbucket server.)

What I find strange is that neither the fetches nor the pushes even
touch these refs (but the bitbucket triggers underneath might).

But my question is whether there are race conditions that can cause
such messages in regular operation - they continue with 'If no other git
process is currently running, this probably means a git process crashed
in this repository earlier.' which indicates some level of anticipation.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

[PATCH] commit: remove 'Clever' message for --only --amend

[Andreas Krey]

That behavior is now documented, and we don't
need a reward afterwards.

Signed-off-by: Andreas Krey <a.k...@gmx.de>
---

> Sorry for making you send an extra round; let's queue the original,
> and if you still are interested, have the "Clever" removal as its
> own patch.

Here you go.

 builtin/commit.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 89b66816f..276c74034 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1208,8 +1208,6 @@ static int parse_and_validate_options(int argc, const 
char *argv[],
die(_("Only one of --include/--only/--all/--interactive/--patch 
can be used."));
if (argc == 0 && (also || (only && !amend && !allow_empty)))
die(_("No paths with --include/--only does not make sense."));
-   if (argc == 0 && only && amend)
-   only_include_assumed = _("Clever... amending the last one with 
dirty index.");
if (argc > 0 && !also && !only)
only_include_assumed = _("Explicit paths specified without -i 
or -o; assuming --only paths...");
if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
-- 
2.11.0.10.g1e1b186.dirty

Re: [PATCH] commit: make --only --allow-empty work without paths

[Andreas Krey]

On Fri, 02 Dec 2016 23:32:55 +, Jeff King wrote:
> On Fri, Dec 02, 2016 at 11:15:13PM +0100, Andreas Krey wrote:
> 
> > --only is implied when paths are present, and required
> > them unless --amend. But with --allow-empty it should
> > be allowed as well - it is the only way to create an
> > empty commit in the presence of staged changes.
> 
> OK. I'm not sure why you would want to create an empty commit in such a
> case.

User: Ok tool, make me a pullreq.

Tool: But you haven't mentioned any issue
  in your commit messages. Which are they?

User: Ok, that would be A-123.

Tool: git commit --allow-empty -m 'FIX: A-123'

Originally we checked that the status output was
empty, and later added an option for 'yes, I know
that there are uncommitted changes; I don't want
them included'.

And then someone had staged changes, which lead me here,
because there is no way now to create an empty commit
(just for the commit message) in that situation.
Amending the previous commit wouldn't fly with us
because of a local ban on non-fast-forward pushes.

...
> > (The interdepence of the tests is a strange thing;
> > making --run=N somewhat pointless.)
> 
> Yes, I think --run is a misfeature (I actually had to look it up, as I
...
> implicit. If a single test script is annoyingly long to run, I'd argue

It wasn't about runtime but about output. I would have
liked to see only the output of my still-failing test;
a 'stop after test X' would be helpful there.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: [PATCH] commit: make --only --allow-empty work without paths

[Andreas Krey]

On Mon, 05 Dec 2016 12:36:19 +, Junio C Hamano wrote:
> Jeff King <p...@peff.net> writes:
> > On Sat, Dec 03, 2016 at 07:59:49AM +0100, Andreas Krey wrote:
...
> >> Tool: git commit --allow-empty -m 'FIX: A-123'
> >
> > OK. I think "tool" is slightly funny here, but I get that is part of the
> > real world works. Thanks for illustrating.
> 
> I am not sure if I understand.  Why isn't the FIX: thing added to
> the commit being pulled by amending it?

Because we don't allow push -f on our blessed repo (bitbucket).
(Oops, answer to wrong question. But the integrators don't want
to meddle with dev's commits, either.)

This has multiple reasons:

- The percentage of people who can and would be willing
  to do rebase -i is small. (Not that they are likely to
  increase under this policy.)

- Our build tool record builds by commit id, and when
  you rebase (even if only for commit message edits)
  you lose your (simple) build history.

> Would the convention be for
> the responder of a pull-request to fetch and drop the tip commit?

No, they need to keep it as there is automation hinging on the FIX line.

I would much prefer people to do rebases/amends instead of this crutch,
but that's not for now.

Hmm, it just occurred to me that we might allow force pushes for specific
users to keep the foot-shooting ratio low.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

[PATCH] commit: make --only --allow-empty work without paths

[Andreas Krey]

--only is implied when paths are present, and required
them unless --amend. But with --allow-empty it should
be allowed as well - it is the only way to create an
empty commit in the presence of staged changes.

Signed-off-by: Andreas Krey <a.k...@gmx.de>
---

I stumbled over this omission trying
to create an empty commit while changes
are staged. (We use such empty commits as
workaround when devs forgot to put issues
into the actual commits. And one had
staged changes at that point.)

Arguably, requiring paths with --only is
pointless anyway because it is implicit
in that case, but I'm happy when it works
like in this patch.

(The interdepence of the tests is a strange thing;
making --run=N somewhat pointless.)

(And I hope that the patch in commit.c is
actually sufficient for this, but have
not found indications to the contrary.)

 Documentation/git-commit.txt | 3 ++-
 builtin/commit.c | 2 +-
 t/t7501-commit.sh| 9 +
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index f2ab0ee2e..4f8f20a36 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -265,7 +265,8 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
If this option is specified together with `--amend`, then
no paths need to be specified, which can be used to amend
the last commit without committing changes that have
-   already been staged.
+   already been staged. If used together with `--allow-empty`
+   paths are also not required, and an empty commit will be created.
 
 -u[]::
 --untracked-files[=]::
diff --git a/builtin/commit.c b/builtin/commit.c
index 8976c3d29..89b66816f 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1206,7 +1206,7 @@ static int parse_and_validate_options(int argc, const 
char *argv[],
 
if (also + only + all + interactive > 1)
die(_("Only one of --include/--only/--all/--interactive/--patch 
can be used."));
-   if (argc == 0 && (also || (only && !amend)))
+   if (argc == 0 && (also || (only && !amend && !allow_empty)))
die(_("No paths with --include/--only does not make sense."));
if (argc == 0 && only && amend)
only_include_assumed = _("Clever... amending the last one with 
dirty index.");
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index d84897a67..0d8d89309 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -155,6 +155,15 @@ test_expect_success 'amend --only ignores staged contents' 
'
git diff --exit-code
 '
 
+test_expect_success 'allow-empty --only ignores staged contents' '
+   echo changed-again >file &&
+   git add file &&
+   git commit --allow-empty --only -m "empty" &&
+   git cat-file blob HEAD:file >file.actual &&
+   test_cmp file.expect file.actual &&
+   git diff --exit-code
+'
+
 test_expect_success 'set up editor' '
cat >editor <<-\EOF &&
#!/bin/sh
-- 
2.11.0.10.g1e1b186

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Races on ref .lock files?

[Andreas Krey]

On Fri, 16 Dec 2016 09:20:07 +, Junio C Hamano wrote:
...
> >   error: cannot lock ref 'stash-refs/pull-requests/18978/to': Unable to 
> > create 
> > '/opt/apps//repositories/68/stash-refs/pull-requests/18978/to.lock': 
> > File exists.
...
> I think (and I think you also think) these messages come from the
> Bitbucket side, not your "git push" (or "git fetch").

I *know* that this is the case - we don't have refs like that
on the local side. (Our users are more scared about them.)

...
> when there are locked refs.  I'd naively think that unless you are
> pushing to that ref you showed an error message for, the receiving
> end shouldn't care if the ref is being written by somebody else, but
> who knows ;-) They may have their own reasons wanting to lock that
> ref that we think would be irrelevant for the operation, causing
> errors.

Possible. I'm going Byrans way for now, disabling the gc there.

But:

In a different instance, we have a simple bare git repo that we
use for backup purposes. Which means there are lots of pushes
going there (all to disjunct refs), and I now cared to look
into those logfiles:

snip
Wed Dec 21 05:08:14 CET 2016
fatal: Unable to create '/data/git-backup/backup.git/packed-refs.lock': File 
exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
error: failed to run pack-refs
To git-backup-u...@socrepo.advantest.com:backup.git
 + 8aac9ae...2df6d56 refs/zz/current -> 
refs/backup/socvm217/ZworkspacesZsocvm217ZjohanabtZws-release_tools.Ycurr 
(forced update)
snip

I interpret this as "I updated the refs files, but packing them
didn't work because someone else was also packing right now."

Is that happening as designed, or do I need to be afraid
that some refs didn't make the push?

To ask differently, is git relying on people reading such
messages and following up on them? And thus isn't that
easy to use in automated processes? (Additional problem:
The user in question, besides being an automat, doesn't
have the capability to work in the target repository.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Races on ref .lock files?

[Andreas Krey]

On Fri, 16 Dec 2016 15:34:22 +, Bryan Turner wrote:
...
> Bitbucket Server developer here.

Social media rock. :-)

> If you'd like to investigate more in depth, I'd encourage you to
> create a ticket on support.atlassian.com so we can work with you.

That is going to be postponed until we update our bitbucket instance
to the current state.

> Otherwise, if you just want to prevent seeing these messages, you can
> either fork the relevant repository in Bitbucket Server (which
> disables auto GC), or run "git config gc.auto 0" in

Doing that for now. Will come back either if it doesn't help,
or after the upgrade.

> within Bitbucket Server instead, so a future upgrade should
> automatically prevent these messages from appearing on clients.

I still wonder if git itself should prevent these, or is there
a (git level) recommendation not to enable auto-gc in repos where
people regularly push to?

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: cherry-pick --message?

[Andreas Krey]

On Tue, 21 Mar 2017 13:00:05 +, Jeff King wrote:
...
> > I have an slightly unusual usecase for cherry-pick:
> > I want to modify the commit message that is used in the process,
> > e.g. do an d/^PROP:/ on it, but unfortunately -m does something
> > else here.
> > 
...
> 
> There's "cherry-pick --edit".

Yes, but. I'm in a toolchain, not a user. I'm a command that let
the user cherry-pick specific things, and I need to edit out the things
that made the original commit eligible to be picked in the first place.

Can't quite rely on the tool's user to do that. :-(

I'm not familiar with the plumbing to know where to look there.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: Re: cherry-pick --message?

[Andreas Krey]

On Tue, 21 Mar 2017 13:33:35 +, Jeff King wrote:
...
> Probably "format-patch | sed | am -3" is your best bet if you want to
> modify the patches in transit _and_ have the user just use normal git
> tools.

Except that 'git am' doesn't have --no-commit like cherry-pick does. :-(
It's always something. (Perhaps I'm instead going to rewrite the commit
before cherry-picking it.)

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

cherry-pick --message?

[Andreas Krey]

Hi all,

I have an slightly unusual usecase for cherry-pick:
I want to modify the commit message that is used in the process,
e.g. do an d/^PROP:/ on it, but unfortunately -m does something
else here.

And there is no --message here for good reason, as cherry-pick
can pick multiple commits and so on. Bad for me, though.

So, am I down to the combo of format-patch and apply, or is there
an easier way? (I'd also like to end up in the same state as with
cherry-pick should there be conflicts.)

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Flurries of 'git reflog expire'

[Andreas Krey]

On Thu, 06 Jul 2017 10:01:05 +, Bryan Turner wrote:

> Do you know what version of Bitbucket Server is in use?

We're on the newest 4.x.

...
> - Run "git config gc.auto 0" in

Going that route.

...
> I also want to add that Bitbucket Server 5.x includes totally
> rewritten GC handling. 5.0.x automatically disables auto GC in all
> repositories and manages it explicitly, and 5.1.x fully removes use of
> "git gc" in favor of running relevant plumbing commands directly.

That's the part that irks me. This shouldn't be necessary - git itself
should make sure auto GC isn't run in parallel. Now I probably can't
evaluate whether a git upgrade would fix this, but given that you
are going the do-gc-ourselves route I suppose it wouldn't.

...
> Upgrading to 5.x can be a bit of an undertaking, since the major
> version brings API changes,

The upgrade is on my todo list, but there are plugins that don't
appear to be ready for 5.0, notable the jenkins one.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Flurries of 'git reflog expire'

[Andreas Krey]

Hi everyone,

how is 'git reflog expire' triggered? We're occasionally seeing a lot
of the running in parallel on a single of our repos (atlassian bitbucket),
and this usually means that the machine is not very responsive for
twenty minutes, the repo being as big as it is.

The server is still on git 2.6.2 (and bitbucket 4.14.5).

Questions:

What can be done about this? Cronjob 'git reflog expire' at midnight,
so the heuristic don't trigger during the day? (The relnotes don't
mention anything after 2.4.0, so I suppose a git upgrade won't help.)

What is the actual cause? Bad heuristics in git itself, or does
bitbucket run them too often (improbable)?

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Flurries of 'git reflog expire'

[Andreas Krey]

On Wed, 05 Jul 2017 04:20:27 +, Jeff King wrote:
> On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote:
...
> I seem to recall that using --stale-fix is also extremely expensive,
> too. What do the command line arguments for the slow commands look like?

The problem isn't that the expire is slow, it is that there are
many of them, waiting for disk writes.

> And what does the process tree look like?

Lots (~ 10) of

  \_ /usr/bin/git receive-pack 
/opt/apps/atlassian/bitbucket-data/shared/data/repositories/68
  |   \_ git gc --auto --quiet
  |   \_ git reflog expire --all

plus another dozen gc/expire pairs where the parent is already gone.
All with the same arguments - auto GC.

I'd wager that each push sees that a GC is in order,
and doesn't notice that there is one already running.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Flurries of 'git reflog expire'

[Andreas Krey]

On Tue, 04 Jul 2017 11:43:33 +, Ævar Arnfjörð Bjarmason wrote:
...
> You can set gc.auto=0 in the repo to disable auto-gc, and play with
> e.g. the reflog expire values, see the git-gc manpage.
> 
> But then you need to run your own gc, which is not a bad idea anyway
> with a dedicated git server.

Actually, bitbucket should be doing this. Although I can't quite
rule out the possibility that we reenabled GC in this repo some
time ago.

> But it would be good to get to the bottom of this, we shouldn't be
> running these concurrently.

Indeed. Unfortunately this isn't easily reproduced in the test instance,
so I will need to get a newer git under the production bitbucket.

There are quite some of

  \_ /usr/bin/git receive-pack 
/opt/apps/atlassian/bitbucket-data/shared/data/repositories/68
  |   \_ git gc --auto --quiet
  |   \_ git reflog expire --all

in the process tree, apparently a new one gets started even though previous
ones are still running. The number of running expires grew slowly, in the
order of many minutes.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Regression in 'git branch -m'?

[Andreas Krey]

Hi everybody,

I got something that looks like a regression somewhere since 2.11.
This script

  set -xe
  rm -rf repo
  git init repo
  cd repo
  git commit -m nix --allow-empty
  git branch -m master/master
  git rev-parse HEAD
  git branch
  git status

causes .git/HEAD to still contain 'ref: refs/heads/master' and to fail
in the rev-parse step with

  + git rev-parse HEAD
  HEAD
  fatal: ambiguous argument 'HEAD': unknown revision or path not in the working 
tree.
  Use '--' to separate paths from revisions, like this:
  'git  [...] -- [...]'

This is with 2.15.0.rc0; with 2.11.0 (and 2.11.0.356.gffac48d09) it still works.

I'm going to do a bisect on this as battery permits.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: git repack leaks disk space on ENOSPC

[Andreas Krey]

On Wed, 11 Oct 2017 20:17:03 +, Jonathan Nieder wrote:
> Hi Andreas,
> 
> Andreas Krey wrote:
> 
> > I observed (again) an annoying behavior of 'git repack':
> 
> Do you have context for this 'again'?  E.g. was this discussed
> previously on-list?

I think I posted about it, but no discussion. I poked a bit
at the code, with not much luck back then.

...
> Does using create_tempfile there seem like a good path forward to you?
> Would you be interested in working on it (either writing a patch with
> such a fix or a test in t/ to make sure it keeps working)?

I will look into creating a patch (thanks for the pointers),
but I don't see how to make a testcase for this - pre-filling the
disk doesn't sound like a good idea. Most people probably won't run in
this situation, and then won't have tmp_packs with a dozen GBytes each
lying around.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800