Re: Creating own hierarchies under $GITDIR/refs ?

[Jed Brown]

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

[Jed Brown]

Ravi Shekhar Jethani  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

[Jed Brown]

Stefan Beller  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?

[Jed Brown]

Junio C Hamano  writes:

> Jed Brown  writes:
>
>> Junio C Hamano  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: git grep: search whole tree by default?

[Jed Brown]

Junio C Hamano  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: Review of git multimail

[Jed Brown]

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

[Jed Brown]

Junio C Hamano  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

[Jed Brown]

$ 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

Re: Find/prune local branches after upstream branch is deleted?

[Jed Brown]

Jeff King  writes:

> On Fri, Apr 19, 2013 at 12:50:48PM -0500, Jed Brown wrote:
>
>> Jeff King  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'.
>
> Yeah, git has no way of knowing that. You can tell it by asking "git
> branch --merged maint" and looking for such topics, of course, but I
> think you are trying to remove as much thinking as possible from the
> process.
>
> So what is the clue that you would like to use to know that the branch
> is stale. Deletion of the branch on the remote?

I was hoping for ("has an upstream set" AND "upstream branch deleted").

> For that, I don't think there is a single command. You can do "git push
> --dry-run --all" and look for new branches that would be pushed, but
> that is kind of hacky.  The answer you want is:
>
>   comm -23 \
> <(git for-each-ref --format='%(refname:short)' refs/heads) \
> <(git for-each-ref --format='%(refname:short)' refs/remotes/origin |
>   sed s,origin/,,)

This also finds my private branches that I just haven't pushed yet.  The
following has what I think are good semantics.

  git for-each-ref --format='%(refname:short) %(upstream)' refs/heads |
while read ref upstream; do
  test -n "$upstream" && (git show-ref -q --verify "$upstream" || echo $ref)
done


FWIW, Git sorts non-alpha characters differently from 'sort'.  This
means that Git output can't be sent to comm without first '| sort'.

$ git branch xy
$ git branch x-y
$ git branch
* master
  x-y
  xy
$ git branch | sort
* master
  xy
  x-y
--
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?

[Jed Brown]

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

Find/prune local branches after upstream branch is deleted?

[Jed Brown]

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: Teaching rerere about existing merges

[Jed Brown]

Jeremy Rosen  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: [RFC/PATH 3/4] remote-hg: add version checks to the marks

[Jed Brown]

Felipe Contreras  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 v2 11/13] remote-hg: force remote push

[Jed Brown]

Joachim Schmitz  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: [PATCH v2 11/13] remote-hg: force remote push

[Jed Brown]

Felipe Contreras  writes:

> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown  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: [PATCH v2 11/13] remote-hg: force remote push

[Jed Brown]

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

[Jed Brown]

Felipe Contreras  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 00/13] remote-hg: general updates

[Jed Brown]

Junio C Hamano  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 00/13] remote-hg: general updates

[Jed Brown]

Felipe Contreras  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 v2 11/13] remote-hg: force remote push

[Jed Brown]

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

[Jed Brown]

Felipe Contreras  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: Segfault with merge-tree on multiple Git versions

[Jed Brown]

Charlie Smurthwaite  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: Segfault with merge-tree on multiple Git versions

[Jed Brown]

Charlie Smurthwaite  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: git branch: multiple --merged and --no-merged options?

[Jed Brown]

Jeff King  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?

[Jed Brown]

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

[Jed Brown]

Junio C Hamano  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

[Jed Brown]

Michael Haggerty  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-' 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

Re: Updating shared ref from remote helper, or fetch hook

[Jed Brown]

Jed Brown  writes:

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

A related issue is that when a remote helper replies to an 'import' with
_only_ a commit in refs/notes/, git (fetch or pull) produces an error
message like

  error: refs/notes/hg-84b3865b750a567acb16929c21e14c4a45a5639b does not point 
to a valid object

but successfully updates the ref (which is indeed valid) and returns
0. I have not been able to determine what exactly git thinks is
invalid. As long as there is at least one non-notes commit in the
stream, no such error message is produced.

Is this behavior intended?
--
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

[Jed Brown]

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