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 note
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
> director
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, y
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
>
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 b
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 cod
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
$ 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 dif
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,
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
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 up
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 unsu
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. Th
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?
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
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 e
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 topi
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 loo
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
interestin
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 upstr
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
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
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
$ g
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 "--merg
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 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-b
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 c
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
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 m
29 matches
Mail list logo
