Re: Creating own hierarchies under $GITDIR/refs ?
John Keeping j...@keeping.me.uk writes: I actually wonder if you could do this with notes and git-grep; for example: git grep -l keeping.me.uk refs/notes/amlog | sed -e 's/.*://' -e 's!/!!g' That should be relatively efficient since you're only looking at the current notes tree. I added notes handling to gitifyhg and would search it similar to this. Since gitifyhg is two-way, I could not modify the commits. Later, when we converted several repositories (up to 50k commits/80 MB), I appended Hg-commit: $Hg_commit_hash to all the commit messages. This way it shows up on the web interface, users don't have to obtain the notes specially, and git log --grep works naturally. I think it's worth considering this simple solution; existing Git users won't mind recloning once. pgp3uBjty3sk1.pgp Description: PGP signature
Re: Rationale behind 'extern' on protypes in .h files
Ravi Shekhar Jethani rsjeth...@gmail.com writes:
To check this I installed the libgit2-dev package which installed:
/usr/include/git2/*.h , /usr/lib/libgit2.so
Now, I exported all symbols using:
$ readelf -s /usr/lib/libgit2.so
and tried to match these with 'externed' prototypes in the Git source
directory..no matches.
I am confused!!!.
libgit2 is an entirely different package from Git. If you look at the
libgit2 sources (https://github.com/libgit2/libgit2), look in
include/git2/common.h:
/** Declare a public function exported for application use. */
#if __GNUC__ = 4
# define GIT_EXTERN(type) extern \
__attribute__((visibility(default))) \
type
#elif defined(_MSC_VER)
# define GIT_EXTERN(type) __declspec(dllexport) type
#else
# define GIT_EXTERN(type) extern type
#endif
I have always used __attribute__((visibility(default))), but the gcc
man page says
extern declarations are not affected by -fvisibility, so a lot of
code can be recompiled with -fvisibility=hidden with no
modifications. However, this means that calls to extern functions
with no explicit visibility use the PLT, so it is more effective to
use __attribute ((visibility)) and/or #pragma GCC visibility to
tell the compiler which extern declarations should be treated as
hidden.
However, I don't understand what the first statement means
(documentation bug?) since -fvisibility=hidden causes functions declared
with 'extern' to be hidden.
symbols.c:
EXTERN int foo(void);
int foo(void) {return 1;}
$ gcc -fvisibility=hidden -DEXTERN=extern -shared -o libsymbols.so symbols.c
$ nm -D libsymbols.so | grep foo
$
meanwhile,
$ gcc -fvisibility=hidden -DEXTERN='__attribute((visibility(default)))'
-shared -o libsymbols.so symbols.c
$ nm -D libsymbols.so | grep foo
055c T foo
Also I checked this:
$ ldd git
There is no 'gitish' .so in the output; it seems everything is packed
inside one executable.
So your second point 'skipping the PLT...' also doesn't seem to apply here.
My comment applied to shared libraries in general, not specifically to
Git (which isn't a shared library).
pgpHYEPGwoA09.pgp
Description: PGP signature
Re: Rationale behind 'extern' on protypes in .h files
Stefan Beller stefanbel...@googlemail.com writes: From my understanding there is no difference for functions declarations being set to extern or not, because extern is the default on functions. There is a difference for shared libraries if you would like to control which symbols are exported. With gcc, for example, you might compile using -fvisibility=hidden. Any functions explicitly declared with extern, bearing __attribute__((visibility(default)), or using visibility pragmas will be exported (similar to __declspec(dllexport) on Windows). Other functions will be internal to the shared library so you don't have to worry about callers depending on those symbols and performance can be a bit better by skipping the PLT and avoiding symbol relocations at load time. See Drepper's guide for more. http://www.akkadia.org/drepper/dsohowto.pdf pgpZa1gqS6XJz.pgp Description: PGP signature
Re: git grep: search whole tree by default?
Junio C Hamano gits...@pobox.com writes: I suspect that it would be too late for 2.0 we want to do sometime early next year, though. How would you manage transition from the current behavior? Warning people to explicitly use . or :/ during some interim period sounds worse than just switching the default behavior. pgpfQuneqo8Z9.pgp Description: PGP signature
Re: git grep: search whole tree by default?
Junio C Hamano gits...@pobox.com writes: Jed Brown j...@59a2.org writes: Junio C Hamano gits...@pobox.com writes: I suspect that it would be too late for 2.0 we want to do sometime early next year, though. How would you manage transition from the current behavior? Warning people to explicitly use . or :/ during some interim period sounds worse than just switching the default behavior. How would I? You're asking that question only because you omitted too much from the quote ;-) I meant that if the proposed migration plan were to be just change it and people will learn (because anything more gradual would actually be worse for users) then is it really too late for Git-2.0? pgp3mQcztjeYU.pgp Description: PGP signature
Re: Review of git multimail
Ramkumar Ramachandra artag...@gmail.com writes:
Yeah, this is good reasoning. And yes, I'm on Arch: python points to
python3, and python2 points to python2.
I'm also on Arch and it has been this way since October 2010 [1].
Ubuntu plans to remove python2 from the desktop CD images in 14.04 [2],
so having code that does not work with python3 will become more painful
pretty soon.
Note that RHEL5 has only python2.4 and will be supported through March,
2017. Since it is not feasible to have code that works in both python3
and any versions prior to python2.6, any chosen dialect will be broken
by default on some major distributions that still have full vendor
support.
A couple of thoughts while we're on the subject:
1. We should probably convert git-remote-{hg,bzr} to use this style
too:
Python-2.6.8 from python.org installs only python2.6 and python, but not
python2, so this will break on a lot of older systems. Some
distributions have been nice enough to provide python2 symlinks anyway.
Michael's rationale that at least the error message is obvious still
stands.
Debian uses an alternatives mechanism to have multiple versions of the
same package
Alternatives is global configuration that doesn't really solve this
problem anyway.
[1] https://www.archlinux.org/news/python-is-now-python-3/
[2] https://wiki.ubuntu.com/Python/3
pgpSMrbzwufrN.pgp
Description: PGP signature
Re: git describe not showing nearest tag
Junio C Hamano gits...@pobox.com writes: Is 'master' a descendant of v3.3? I.e. what does git rev-list master..v3.3 say? Yes, this shows nothing. Although 'master' is a descendant of v3.3, it is not a --first-parent descendant of anything after v3.0.0. -- 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 describe not showing nearest tag
$ git rev-list --count v3.2..master 9651 $ git rev-list --count v3.3..master 6378 $ git describe --tags master v3.2-9651-ga018267 I would have expected to see v3.3-6378-ga018267, given the documentation: If multiple tags were found during the walk then the tag which has the fewest commits different from the input committish will be selected and output. Here fewest commits different is defined as the number of commits which would be shown by git log tag..input will be the smallest number of commits possible. What's going on here? The repository: https://bitbucket.org/petsc/petsc This repository currently uses only lightweight tags. As an experiment, I replaced both v3.2 and v3.3 with annotated tags, but it did not affect the 'git describe' output. -- 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
Find/prune local branches after upstream branch is deleted?
Consider this workflow: $ git checkout -b my/branch hack, commit, ... $ git push -u origin my/branch The branch gets reviewed, merged, and eventually deleted upstream. The remote tracking branch gets pruned via 'git fetch --prune' or 'git remote prune', but that leaves my local branch with an upstream that has been deleted. Is there a good way to discover this so I can prune my local branches? $ git branch -vv my/branch6d32ec0 [origin/my/branch] The commit message I can script it, but this seems like a pretty common thing. -- 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: Find/prune local branches after upstream branch is deleted?
Jeff King p...@peff.net writes: Try git branch --merged master to get a list of branches that have already been merged. That's what I use, but I was hoping for something more precise. For example, a branch that started at 'maint' would show up there, but its integration hasn't completed until it makes it back to 'maint'. -- 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: Teaching rerere about existing merges
Jeremy Rosen jeremy.ro...@openwide.fr writes: is there a way to teach rerere about existing merge commits, or do I have to re-solve all the existing merge manually once ? See src/contrib/rerere-train.sh and Junio's blog. http://git-blame.blogspot.com/2012/04/rebuilding-git-integration-environment.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/13] remote-hg: force remote push
Joachim Schmitz j...@schmitz-digital.de writes: Jed Brown wrote: Really? If there is no Hg Team, why bother with an Hg upstream? Huh? the counterpart of every user wpuld be some users and not no user or no HG team, isn't it? I'm not sure what you're getting at here, but the whole premise of a two-way git-remote-X is that the users of git-remote-X have less influence in the project than the users of X have in the project. Usually this means that the project workflow is whatever the X users find comfortable rather than whatever git-remote-X users prefer. If you are the sole publisher to a remote repository, sending pull requests to upstream, and if they are comfortable with pulling bookmarks (much more likely if they use a pull-request model rather than a shared repo), then force-pushing by default is more reasonable. An imperfect analogy is Git's push.default=simple, which is more friendly to beginners and to those sharing a remote. -- 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/PATH 3/4] remote-hg: add version checks to the marks
Felipe Contreras felipe.contre...@gmail.com writes: @@ -76,12 +78,19 @@ class Marks: def __init__(self, path): self.path = path +self.clear() +self.load() + +if self.version VERSION: +self.clear() It's friendlier to just upgrade the marks in-place. This takes less than one second to run on repositories where full re-import would take half an hour: def upgrade_marks(self, hgrepo): if self.marks_version == 1: # Convert from integer reversions to hgsha1 warn(Upgrading marks-hg from hg sequence number to SHA1) self.marks_to_revisions = dict( (mark, hghex(hgrepo.changelog.node(int(rev for mark, rev in self.marks_to_revisions.iteritems()) self.revisions_to_marks = dict( (hghex(hgrepo.changelog.node(int(rev))), mark) for rev, mark in self.revisions_to_marks.iteritems()) self.marks_version = 2 warn(Upgrade complete) https://github.com/buchuki/gitifyhg/commit/23a6709efd14f3e058e3a846624b7677d1e8b497#L0R195 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] remote-hg: general updates
Felipe Contreras felipe.contre...@gmail.com writes: I still don't see any good reason why a user might prefer gitifyhg, even more importantly, why gitifyhg developers don't contribute to remote-hg. Felipe, I read your blog announcement [1] and got the impression that remote-hg was ready for daily use. When I tried to use it, it promptly crashed in my first attempt to clone. I opened up the script, fixed whatever caused the first stack trace and made it slighly further before it crashed again. I couldn't tell what was expected to work, what was a known problem, and what was an unknown problem. Many things clearly did not work and it had the look of a project that was not getting active use. I felt that it was wildly oversold and that putting it into git.git was premature. I tried gitifyhg later and it basically worked out of the box. All known problems were marked by 'xfail' test cases. At that time, remote-hg failed almost all the gitifyhg tests. I contributed a few things to gitifyhg, including the notes support (essential when talking via email with other people using Mercurial). Since then, the last major project I'm involved with has switched to Git so I rarely need gitifyhg or remote-hg any more. FWIW, I also thought Dusty's original announcement oversold gitifyhg, but it was closer to the truth and upon cloning the repo, it was more clear what didn't work. The early history of gitifyhg is quite chaotic and I didn't realize at first how much code turned out to be borrowed from remote-hg. I don't know whether you wrote all of remote-hg or borrowed significant parts from elsewhere. To be honest, I don't really care, but it would be good to coalesce around one project that is well-tested and has documented behavior so that the poor folks stuck with Mercurial upstreams can have dependable behavior. [1] http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/13] remote-hg: force remote push
Felipe Contreras felipe.contre...@gmail.com writes: Ideally we shouldn't do this, as it's not recommended in mercurial documentation, but there's no other way to push multiple bookmarks (on the same branch), which would be the behavior most similar to git. The problem is that you're interacting with a Mercurial upstream, not a Git upstream. When you're in their playground, you have to play by their rules. Creating new heads is disruptive and not likely to be appreciated. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] remote-hg: general updates
Felipe Contreras felipe.contre...@gmail.com writes: Where is the evidence? You say remote-hg doesn't work, I say it does, the difference is that I have evidence to prove it. There are many projects that don't do what they claim. I gave remote-hg a few minutes and moved on since (at the time) it didn't seem interesting enough to be worth the effort of making proper bug reports. There's a lot of low-quality code in the world and I'm willing to tolerate a certain false-positive rate. I apologize for misdiagnosing your project and I'm happy to believe that you have since fixed the bugs. I was merely answering you question of why some of us contributed to gitifyhg in preference to remote-hg. I see no value in dwelling on the value judgement I made a few months ago. Additionally, I have almost no use for either project any more. remote-hg doesn't fail with the non-fast-forward error, in fact, it doesn't fail at all, it pushes correctly, and that's reported as a failure. I don't agree that force-pushing by default is correct behavior. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] remote-hg: general updates
Junio C Hamano gits...@pobox.com writes: So,... is there a concrete proposal for _me_ to act on? Do you want to see contrib/remtote-hg out of my tree, and have it compete with the other one (which also shouldn't be in my tree) in the open? Three months ago, I would have said yes. Now I don't know. It looks like remote-hg has improved and is perhaps stable enough to remain, but I think it needs a much more complete test suite [1] and some visible documentation about its mapping semantics. There is no way a change like force-push by default should come without the user knowing about it. (I don't think force-push should become the default in any case, but something is wrong with the process if there isn't a good way to communicate such behavioral turmoil.) A separate project making its own releases has a more visible place to indicate such changes. [1] Max and I have no love for the obfuscated shell scripting in gitifyhg's 'py.test'- and 'sh'-based test suite, and we expressed early on that we'd rather have git-style shell scripts. So while porting these would provide a good start, they can't just be dropped into git.git. -- 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 11/13] remote-hg: force remote push
Felipe Contreras felipe.contre...@gmail.com writes: If that's the case, they should disable in the server, just like some people disable non-fast-forward pushes in git. I don't know how to make Hg allow new branches and bookmarks, but not new anonymous heads. Vanishly few Hg projects use a workflow anything like topic branches so it's normally not a common thing to be creating new heads. If someone is using remote-hg, we can be pretty sure they are not the primary maintainer, so if they are pushing, they'll be aware of upstream policy and will need to play by those rules. The problem is Mercurial, purely and simple, without forcing the push, how do you expect this to work? % git clone hg::whatever % git checkout -b feature-a master # do stuff % git push -u origin feature-a There is a difference between pushing a new branch (see 'hg push --new-branch -b branch-name') and creating arbitrary new heads. In a very common case where multiple people are pushing to the same branch/bookmark, force push creates new anonymous heads that share the same branch. (For less familiar readers, hg branches can have multiple heads, though most commands will behave as though the latest head to appear in the repository is the unique head associated with a given branch. Yes, it's insane.) Normal workflow in case of new commits upstream is to 'hg pull --rebase' or to pull and merge (yucky for first-parent, but most Hg users are far from caring about such things). Silently creating new anonymous heads is a bad default. Note: I don't know of any way to avoid the race condition when pushing a bookmark that creates a new head since there is no 'hg push --new-bookmark'. -- 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 11/13] remote-hg: force remote push
Felipe Contreras felipe.contre...@gmail.com writes: [...] will need to play by those rules. No, we don't. The fact that you say so doesn't make it so. Then perhaps we have different goals [1]. I don't know any Git User that would prefer to have an Hg upstream accessed through remote-hg. We have to assume that every Git (remote-hg) User is dealing with Hg Team that is setting the rules, since otherwise Git User would just change the whole damn project to Git and be done with it. In that sense, it is inappropriate to do things that are likely to make Hg Team yell at Git User. I create a branch felipec-bookmarks, and I push as many heads as I wish. Who will get affected? Nobody. Every Hg user will see those heads by default every time they run 'hg log' or 'hg heads'. And who says we are committing upstream? The discussion is moot if you don't want to push your commits upstream. [1] As I mentioned earlier, I don't need either tool any more. -- 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 11/13] remote-hg: force remote push
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown j...@59a2.org wrote:
Then perhaps we have different goals [1]. I don't know any Git User that
would prefer to have an Hg upstream accessed through remote-hg.
Who cares? If you don't know somebody, does that mean such person
doesn't exist?
Maybe I wasn't explicit enough:
I don't know any Git User that would prefer to have an Hg upstream
accessed through remote-hg *than to have a Git upstream accessed
through native Git.*
We have
to assume that every Git (remote-hg) User is dealing with Hg Team
No, we don't.
Really? If there is no Hg Team, why bother with an Hg upstream?
If you are always going to do Mercurial workflows, then what's the
point of using Git?
Using Git workflow locally while being able to interact with the Hg Team
via whatever conventions they have established. Sane branching, merge
strategies, rerere, and a host of other Git features are plenty useful,
even when contained within your personal repo.
Wow, catastrophic. BTW. Any commit pushed will show in 'hg log' either
way. And who will run 'hg heads' if, according to you, the project has
stated that new heads should not be pushed? If no new heads are
pushed, 'hg heads' will never show anything interesting.
Is that the *HUGE* problem? Too many heads will show in the arcane 'hg
heads'?
Hg displays warnings about multiple heads, suggests that you merge them
any time they are anonymous, and doesn't have remote namespaces so that
names can collide. Remember that the most common reason people give for
using Hg in the first place is that it's simpler (yeah, I don't agree
either, but that's their story). So don the hat of a Git (remote-hg)
User: You're interacting with people that don't understand version
control very well and only know the basic Hg command set. Do you really
think it's okay to silently put them in a state where Hg will print
confusing messages about multiple heads, disrupt their workflow ('hg
log'), and suggest that they do things that are likely to be disruptive
(like merge those heads)?
I've spent the last five years as an active contributor to an Hg-based
project and throughout that time, newer contributors would constantly
get flustered over things like this and I would get the emails asking
what happened and how to fix it. Over that five year period, several
other Hg projects that I was involved in switched to Git. My statements
about what is likely to be acceptable to an Hg upstream is based on my
experience with these projects and with a couple remaining Hg holdouts
(scientific applications that I support through libraries). In none of
those projects would a force push have been acceptable.
And who says we are committing upstream?
The discussion is moot if you don't want to push your commits upstream.
There are so many workflows and use cases you are completely ignoring.
Examples? I'm just summarizing the workflows that I encounter and that
other contributors to gitifyhg encounter. You have said yourself that
you don't actually use remote-hg [1], so why are you so confident that
you know what workflows are desirable to remote-hg users?
Anyway, I'm not going to discuss with you any more, a configuration
option would work perfectly, and curiously you didn't comment on that.
Sorry, defaults matter and project philosophy matters. The fact that we
are arguing about such basic things has convinced me that I can't
recommend remote-hg because I have no confidence that the behavior will
be remotely acceptable to a Git user working with an Hg Team.
My primary project switched to Git three weeks ago and there is already
less confusion, despite having adopted a master/next/topic branch
workflow that only two of us were familiar with prior to the switch.
For this reason, I no longer have a vested interest in remote helpers so
I don't intend to debate this issue further.
But please try to make tools for actual users rather than hypothetical
users, or at least don't act so incredulous when people are less than
thrilled about using or contributing to your project.
[1] http://article.gmane.org/gmane.comp.version-control.git/219988
--
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: Segfault with merge-tree on multiple Git versions
Charlie Smurthwaite char...@atechmedia.com writes: I am also using this to obtain a diff that would be applied if a merge were to be run. Is there a better way to obtain this information that is more commonly used? You can do an actual merge using detached HEAD: $ git checkout --detach upstream-branch $ git merge topic-branch This has the benefit that if there are conflicts, you can resolve them here and commit the result so that rerere can auto-resolve them later. Are you looking for something that can be run in a bare repo? -- 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: Segfault with merge-tree on multiple Git versions
Charlie Smurthwaite char...@atechmedia.com writes: Yes, I would need to be able to do this on a bare repo for my use case. And if it's on the server, you don't want this to be observable, so you don't want HEAD to move around. I don't know a better way than: $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo $ cd /tmp/merge-repo $ git pull URL incoming-branch Cloning with --shared just writes a path into .git/objects/info/alternatives and it doesn't need to be on the same file system (unlike --local). Since 'git merge-tree' just works with trees, it has less information than 'git merge'. -- 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 branch: multiple --merged and --no-merged options?
Jeff King p...@peff.net writes: On Fri, Mar 15, 2013 at 02:38:12PM -0500, Jed Brown wrote: $ git branch --no-merged master --merged next Yeah, sadly that does not work, as we use the same slot for the flag and store only one of the two (and we also allow only one --merged head, even though you could in theory want to know merged to X, or merged to Y). Hmm, I would have said conjunction (AND) was more natural than disjunction (OR). If we add support for multiple '--merged' and '--no-merged', do we expect to eventually have a full query grammar? -- 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 branch: multiple --merged and --no-merged options?
I find myself frequently running commands like this $ comm -12 (git branch --no-merged master) (git branch --merged next) when checking for graduation candidates. Of course I first tried $ git branch --no-merged master --merged next but this is equivalent to $ git branch --merged next Isn't this query common enough to have a nicer interface? What do other people use? -- 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 v3 0/8] Hiding refs
Junio C Hamano gits...@pobox.com writes: I am not sure about pushing part, but the jc/fetch-raw-sha1 topic (split from the main jc/hidden-refs topic) should allow your script, after the client learns the set of smudged object names, to ask for git fetch $there $sha1_1 $sha1_2 ... Well, my out-of-band knowledge is currently the sha1 of the data contained in the blob I want, not the blob sha1 itself [1]. After experimenting with jc/hidden-refs, I think it already does exactly what I want. Specifically, I set this on the server git config uploadpack.hiderefs refs/fat so that 'git ls-remote' no longer transfers these refs. Then on the client, I do contentid=$(sha1sum thefile | cut -f1 -d \ ) blobid=$(git hash-object -w thefile) git update-ref refs/fat/$contentid $blobid more like this git push the-remote refs/fat/$contentid ... and later, I can fetch specific refs using git fetch the-remote refs/fat/$wanted:refs/fat/$wanted ... The client knows the desired refs out-of-band so this looks okay. It would be convenient to have '--stdin' options to 'git push' and 'git fetch'. Would a patch for that be welcome? [1] The reason for using $contentid instead of $blobid in the key here is to avoid etching the backend=git detail into the cleaned commits. -- 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 v3 0/8] Hiding refs
Michael Haggerty mhag...@alum.mit.edu writes: A first weakness of your proposal is that even though the hidden refs are (optionally) fetchable, there is *no* way to discover them remotely or to bulk-download them; they would have to be retrieved one by one using out-of-band information. And if I understand correctly, there would be no way to push hidden references remotely (whether manually or from some automated process). Such processes would have to be local to the machine holding the repository. I'm the author of git-fat [1], a smudge/clean filter system for managing large files. I currently store files in the file system (.git/fat/objects) and transfer them via rsync because I want to be able to transfer exact subsets requested by the user. I would like to put this data in a git repository so that I can take advantage of packfile compression when applicable and so that I can use existing access control, but I would need to store a separate reference to each blob (so that I can transfer exact subsets). My refs would be named like 'fat-SHA1_OF_SMUDGED_DATA' and are known on the client side because they are in the cleaned blob (which contains only this SHA1 and the number of bytes [2]). I believe that my use case would be well supported if git could push and pull unadvertised refs, as long as basic operations were not slowed down by the existence of a very large number of such refs. [1] https://github.com/jedbrown/git-fat [2] We could eliminate the performance problem of needing to buffer the entire file if the smudge filter could be passed the object size as an argument and if we could forward that size in a stream to 'git hash-object --stdin'. -- 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
Updating shared ref from remote helper, or fetch hook
I'm working on an hg remote helper that uses git notes for the sha1 revision, so that git users can more easily refer to specific commits when communicating with hg users. Since there may be multiple concurrent fast-import streams, I write the notes to a private ref (refs/notes/hg-REMOTE), to be merged eventually using git notes --ref hg merge hg-REMOTE* There will never be conflicts because each hg commit translates to a unique git commit, thus even if multiple concurrent remotes process the same commit, the corresponding note will match. Unfortunately, I couldn't find a safe way to get this run after a fetch or clone. Of course I can ask the user to arrange to have this command run, but it would be a better interface to have it run automatically since it is a natural responsibility of the remote helper. Am I missing a way to do this or a viable alternative approach? -- 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
