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
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
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.
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
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
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
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
$ 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
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
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
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.
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
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
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
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
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)
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
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
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.
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
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
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
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
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
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,
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
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
27 matches
Mail list logo
