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
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 upda
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 mess
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
--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
---
I stumbled over this omission trying
to create an
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 t
On Mon, 05 Dec 2016 12:36:19 +, Junio C Hamano wrote:
> Jeff King 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
igned-off-by: Andreas Krey
---
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"?&#x
That behavior is now documented, and we don't
need a reward afterwards.
Signed-off-by: Andreas Krey
---
> 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 y
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 't
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
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
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) pe
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 seco
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.loc
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 th
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
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 th
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
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 ju
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
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 c
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:
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 real
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 min
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 commi
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 fo
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.
Hi everyone,
there is an interesting wart around prompt.c -
PROMPT_ECHO isn't used in invoking an external helper program.
Thus, if I clone something on https (which requires auth for that),
and have SSH_ASKPASS set, I will get two GUI *password* prompts,
even though the first one will indicate i
On Mon, 01 Jul 2019 12:48:16 +, Bryan Turner wrote:
...
> In other words, when I locally do:
> git checkout --no-track -b bturner-some-bugfix origin/release/5.16
>
> release/5.16 is the "parent branch" of my bugfix branch and, when I
> push my branch and try to open a pull request, release/5.1
Hi everybody,
I've now located why our backup repo shrinks every month:
git gc --prune=2d
doesn't do what I expected, and differs a lot from --prune=48h.
The latter actually means 'older than two days', while the
former is 'since the second day of this month, same time as now'.
Even '2d ago'
Hi everybody,
I'm currently looking into more aggressively sharing space between multiple
repositories,
and into getting them to share again after one did a repack (which costs us 15G
space).
One thing I stumbled on is the /proc/sys/fs/protected_hardlinks stuff which
disallows
hardlinking pack
On Fri, 24 Aug 2018 16:48:37 +, Ævar Arnfjörð Bjarmason wrote:
...
> I don't understand how this hardlink approach would work (doesn't mean
> it won't, just that I don't get it).
I just detect whether there is insufficient sharing (df is quite handy
here; 'df this/.git that/.git' tells the uns
Hi everyone,
I've been reading up on the current state of git submodules
(our customer's customers want to use them, causing a slight
groan from our customer).
The usability thing I wonder about - with git submodule update,
is it necessary to detach the head to the current (or upstream)
head, ins
Hi everybody,
we just stumbled over a situation in which a merge commits
staged changes into the merge commit. This happens when the
merged-in branch does have commits ('main') but has the same
tree ('--allow-empty') as the merge base:
git init
echo eins >a
git add a
git commit -m
Hi everybody,
I think I have discovered a problem with clone/fetch --shallow-since:
When a ref that is fetches has a head that is already older than
the 'since' time, then the entire branch is fetched, instead of
just the current commit.
Repro:
rm -rf tmp out deep
git init tmp
for i in `se
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 g
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 serv
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&#
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.
Hi everybody,
I'm just looking at some scripts that do a 'git branch --contains $id --remote'
for each new commit in a repo, and unfortunately each invokation already
takes four minutes.
It feels like git branch does the reachability detection separately
for each branch potentially listed. The al
On Thu, 22 Feb 2018 03:05:35 +, 'Peter Backes' wrote:
...
> The bigger issue is usually to copy with those pesky leap seconds. It
> makes a difference whether one uses solar seconds ("posix" style; those
> are more commonly seen) or atomic seconds ("right" style) for the UNIX
> timestamp.
I
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 o
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
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 som
Hi everyone,
I'm seeing the message
remote: warning: ignoring extra bitmap file:
./objects/pack/pack-2943dc24pack
and indeed, there is such a thing (two, actually):
171736188 Aug 17 08:20 pack-2943dc2477026f87b280ebcefa93fe28412688df.idx
12662268 Aug 17 08:24 pack-2943dc2477026f8
On Fri, 18 Aug 2017 02:53:34 +, Jeff King wrote:
...
> Whether there's a .bitmap doesn't impact whether .pack and .idx files
> are deleted. The next full repack would pack everything into a new big
> pack, and then delete any existing files, including .pack, .idx, and
> .bitmap.
It took a bit
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: re
Hi all,
I observed (again) an annoying behavior of 'git repack':
When the new pack file cannot be fully written because
the disk gets full beforehand, the tmp_pack file isn't
deleted, meaning the disk stays full:
$ df -h .; git repack -ad; df -h .; ls -lart .git/objects/pack/tmp*; rm
.git/obje
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
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 thei
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 coll
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
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.
Andre
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
> "mai
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
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 o
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^
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
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 prett
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
--
"
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 a
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 t
On Wed, 15 Jan 2014 14:00:30 +, David Kastrup wrote:
> Andreas Krey 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
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
D
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
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
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 ther
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 pac
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_
>
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 defaul
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
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
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 beca
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
Hi everyone,
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,
but apparently some variation of the alphabetically first
or temporally last, or the last *new* branch pushed.
Wher
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
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&#x
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 eithe
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 onl
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;
i
From: Junio C Hamano
This implements the server side of protocol extension to show which branch
the HEAD points at. The information is sent as a capability symref=.
Signed-off-by: Junio C Hamano
Signed-off-by: Andreas Krey
---
upload-pack.c | 8 ++--
1 file changed, 6 insertions(+), 2
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
tra
Signed-off-by: Andreas Krey
---
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
From: Junio C Hamano
Signed-off-by: Junio C Hamano
Signed-off-by: Andreas Krey
---
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
On Fri, 06 Sep 2013 10:56:51 +, Junio C Hamano wrote:
> Andreas Krey writes:
>
...
> > + if (symref) {
> > + ref->symref = xcalloc(symref_len + 1, 1);
> > + strncpy(ref->symref, symref, symref_len);
> > +
On Fri, 06 Sep 2013 10:46:24 +, Junio C Hamano wrote:
> Andreas Krey writes:
>
...
> reason later, on-the-wire format should be prepared to support such
> later enhancement. I think sending
>
> symref=HEAD:refs/heads/master
Mirco-bikeshed: Should that possibly be
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 th
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
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 wor
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
---
This brings 'git clean -ndx' times down from 17 minutes
to 11 seconds on one of our
On Mon, 16 Mar 2015 10:23:05 +, Junio C Hamano wrote:
> Andreas Krey 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
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 ho
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 th
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 h
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 runni
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
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
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 c
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 histo
1 - 100 of 117 matches
Mail list logo
