* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Pierre Habouzit @ 2008-10-28 13:19 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028131116.GA8272@artemis.googlewifi.com>
[-- Attachment #1: Type: text/plain, Size: 3122 bytes --]
On Tue, Oct 28, 2008 at 01:11:16PM +0000, Pierre Habouzit wrote:
> On Tue, Oct 28, 2008 at 05:45:40AM +0000, Jeff King wrote:
> > On Mon, Oct 27, 2008 at 01:07:10PM -0700, Linus Torvalds wrote:
> > > Of course, if the commit is reachable through multiple sources (which is
> > > common), our particular choice of "first" reachable is entirely random
> > > and depends on the particular path we happened to follow.
> >
> > Hmm. It would be nice to keep even a simple counter to get a "distance"
> > from the ref and choose the one with the smallest distance (I think we
> > can get away without the complex rules that git-describe uses, since we
> > are not interested in describing the full commit, but rather finding a
> > "likely" branch).
> >
> > However, that would require making multiple passes over the commit
> > graph, which might impact the startup speed.
>
> Actually I tried to do that (and you meant name-rev --contains rather
> than describe actually ;p), and I stopped because it's too slow. I
> believe the proper way to do that is to help git-log knowing which are
> the short (topic) branches, and to crawl incrementally using a
> date-based hack. This would basically work a bit like this. Let's
> imaging you want to crawl "next" in git and know which topics from pu
> are in it. You would say e.g.:
>
> git-log --topics=*/* next (as pretty much every */* is a topic branch
> for git.git).
>
>
> Then one has to know which are the heads of every topic branches first,
> then crawl next the usual way, except that when you arrive to a point
> that is a topic branch head, you don't look that way. You remember the
> date of that point, and continue to crawl "next" a bit further so that
> you can start annotating the topic's commits you've stumbled upon. And
> you do that, you look at jd/topic (as in John Doe topic branch) and mark
> all the commits as being from jd/topic, until you either go back to some
> commit from next, or your current commit date is younger than your
> current "next" crawling front. In the former case, you're done with that
> topic, in the latter you must continue to preprocess "next" a bit more.
My description is clumsy, as we probably sometimes want to crawl topics
that aren't merged either like in git-log --topics=*/* --all. But we
just have to mark the current "front" of the walk, and have it sorted
between things that are part of topic heads and the thing that are not.
We don't even need to decorate the things that are _not_ part of the
topics at all I'd say, because that's where you definitely need distance
based algorithms and multiple passes to yield correct results.
Whereas for the specific case of topic branches, which is what people
want (see Ingo's mails on the subject a week or so ago), the algorithm I
propose is, I guess, mostly O(n + m) in the number of walked commits (n)
and references (m). IOW fast.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: new plan for cleaning up the worktree mess, was Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-28 13:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211955250.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 10/22/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 21 Oct 2008, Jeff King wrote:
>
> > On Tue, Oct 21, 2008 at 07:02:48PM +0200, Johannes Schindelin wrote:
> >
> > > So I propose this change in semantics:
> > >
> > > - setup_git_directory_gently(): rename to discover_git_directory(),
> > > and avoid any chdir() at all.
> > > - setup_git_directory(): keep the semantics that it chdir()s to the
> > > worktree, or to the git directory for bare repositories.
> > >
> > > Using _gently() even for RUN_SETUP builtins should solve the long
> > > standing pager problem, too.
> >
> > I'm not sure there aren't hidden problems lurking in that strategy
> > (every time I look at this area of code, something unexpected prevents
> > what I think should Just Work from Just Working), but I think that is a
> > promising direction to go for clearing up some of the long-standing
> > issues.
>
> Same here. I grew a pretty strong opinion about the whole worktree thing,
> but maybe that is only because it was done trying to change as little as
> possible.
I played a bit with code, extracted discover_git_directory() from
setup_git_directory_gently() then made the latter a wrapper of the
former with chdir(). Some more for thoughts from the experiment.
1. Because discover_git_directory() does not do chdir() until later in
setup_git_directory_gently(), setting GIT_DIR to a relative path seems
unsafe (or worse unset at all, in case .git is found in parent
directories). But making GIT_DIR absolute path breaks tests because
some of them expect "git rev-parse --git-dir" to return a relative
path. The approach used in 044bbbc (Make git_dir a path relative to
work_tree in setup_work_tree()) can be reused to performance loss, but
that won't solve the issue.
2. 044bbbc also brings up another issue: code duplication between
setup_git_directory_gently() and setup_work_tree(). The new
setup*gently() can be roughly like this if setup_work_tree() can
calculate prefix too:
const char *setup_git_directory_gently(int *nongit_ok)
{
int nonworktree_ok;
/*
* Let's assume that we are in a git repository.
* If it turns out later that we are somewhere else, the value will be
* updated accordingly.
*/
if (nongit_ok)
*nongit_ok = 0;
if (!discover_git_directory()) {
if (nongit_ok) {
*nongit_ok = 1;
return NULL;
}
die("Not a git repository");
}
return setup_work_tree_gently(&nonworktree_ok); // gentle version
}
So I propose to make setup_work_tree() return a prefix, relative to
current cwd. The setup procedure then would become:
if (discover_git_directory())
die("Git repository needed");
prefix = setup_work_tree(); // die() inside if cannot setup worktree
3. Dealing with cwd outside worktree. If cwd is inside a worktree,
prefix will be calculated correctly. If it is outside, the current
behavior (with both GIT_DIR and GIT_WORK_TREE set) is leave prefix as
NULL. I think that is not right. With a wrong prefix, git commands
will not be able to access on-disk files. I would propose either:
- die() if cwd is outside worktree
- setup*gently() discovers the situation and gives up, then lets git
commands handle themselves. Some commands, like git-archive, don't
care about on-disk files at all, they could just simply ignore the
prefix and keep going. Others may die() or handle it properly.
Again, this breaks things.
--
Duy
^ permalink raw reply
* Re: [VOTE] git versus mercurial
From: Johannes Schindelin @ 2008-10-28 14:28 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <ge70nl$l6t$1@ger.gmane.org>
Hi,
On Tue, 28 Oct 2008, walt wrote:
> walt wrote:
> > No, no, I'm not the one calling for a vote. You old-timers here will
> > know the name Matt Dillon, who is leading the dragonflybsd project
> > (www.dragonflybsd.org).
> >
> > Matt is the one who is calling for the vote in his thread "Vote for
> > your source control system" in the dragonfly.kernel group, accessible
> > via nntp://nntp.dragonflybsd.org...
>
> The official vote was 19 to 19, plus one for perforce and one for svn.
> Matt has proposed a primary git repository and a mirror in hg, and
> that's being debated now.
While many may say that that is a half-baked solution, I actually like it.
Mercurial and Git are pretty similar in their concept (if not in how the
data is actually stored).
Note that with git fast-export and hg fast-import, it should be relatively
simple to convert from one data format to the other, even incrementally.
And for the other direction, you could use hg fast-export from the
fast-export.git repository (I am working on a better one at the moment,
too, so that incremental fast-export would be possible, too).
Ciao,
Dscho
^ permalink raw reply
* Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Peter Krefting @ 2008-10-28 14:41 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0810281445190.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin:
> While many may say that that is a half-baked solution, I actually
> like it. Mercurial and Git are pretty similar in their concept (if
> not in how the data is actually stored).
That touches on something that I have been thinking about for a while.
How difficult are the storage formats? Would it be possible, in a
reasonable amount of work, to add support for the Mercurial protocol
and format in "git clone", so that I could clone a Mercurial repository
and work on it with Git, and then possibly use "git push" to possibly
push the result back to Mercurial?
It seems to me that use of DVCS is polarising between Git, Mercurial
and Bzr. It would be nice to have easy interoperability between the
systems, at least as far as can be covered by the lowest common
denominator of what they support. I would love to be able to use Git to
clone a Bzr repository that I need to be able to access, since bzr is
just different enough from Git to be annoying. Same goes for Mercurial.
And I am sure that users of the other tools feel the same.
Would it be possible to design a common transfer format that could be
implemented by all three (and that would be a little smarter than
fast-export/fast-import)?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Johannes Schindelin @ 2008-10-28 14:59 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0810281536360.27029@ds9.cixit.se>
Hi,
On Tue, 28 Oct 2008, Peter Krefting wrote:
> How difficult are the storage formats? Would it be possible, in a
> reasonable amount of work, to add support for the Mercurial protocol
> and format in "git clone", so that I could clone a Mercurial repository
> and work on it with Git, and then possibly use "git push" to possibly
> push the result back to Mercurial?
There was talk about imitating Mercurial's wire protocol in order to have
an efficient HTTP server. Shawn is working on that front;
We discussed it briefly, and there might be some cute ways to copy it:
since we are not append-only, we have to download the pack index first
(which is not downloaded ATM, as we generate it from the downloaded pack
while verifying it). With that index, we can determine which parts we
need in order to regenerate the pack; it would still be pretty stupid when
there are a lot of branches and we are really only interested in one of
them.
But I doubt that it will be possible to use the wire protocol to pull/push
between different DVCSes. I _strongly_ doubt that the SHA-1s in the
Mercurial repositories could _ever_ be reused in Git mirrors of them, as
our data format (on which the hash depends) is different.
> It would be nice to have easy interoperability between the systems, at
> least as far as can be covered by the lowest common denominator of what
> they support. I would love to be able to use Git to clone a Bzr
> repository that I need to be able to access, since bzr is just different
> enough from Git to be annoying. Same goes for Mercurial. And I am sure
> that users of the other tools feel the same.
Wasn't bzr touting it as one of their major features that they could have
foreign-scm remotes? If I remembered that correctly, that might be the
route you want to take.
Ciao,
Dscho
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Matthieu Moy @ 2008-10-28 15:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0810281551040.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Wasn't bzr touting it as one of their major features that they could have
> foreign-scm remotes? If I remembered that correctly, that might be the
> route you want to take.
Yes, see http://bazaar-vcs.org/BzrForeignBranches . That can be
compared to git-svn for git, except that one uses the exact same
command set to interact with the remotes (i.e. you "bzr push" to an
svn repository, while you would "git svn dcommit" with git).
There are read-only implementations of Git and Mercurial foreign
branches. AFAIK, unfortunately, they're more proof of concepts than
real "production ready" plugins.
--
Matthieu
^ permalink raw reply
* Re: Gitk/Cygwin bug: phony local changes
From: Hannu Koivisto @ 2008-10-28 15:12 UTC (permalink / raw)
To: git
In-Reply-To: <83bpx62hbn.fsf@kalahari.s2.org>
Hannu Koivisto <azure@iki.fi> writes:
> Greetings,
>
> git clone git://git.kernel.org/pub/scm/git/git.git
> cd git
> gitk
>
> with Cygwin build of git version 1.6.0.3.523.g304d0 in Windows XP
> SP2 with Cygwin dll version 1.5.24 results to gitk showing "Local
> uncommitted changes, not checked in to index" entry in the history
> tree and if I select that entry, it seems to indicate that all
> files have changed but without any actual content changes.
>
> git status doesn't show any changes.
>
> If I run git diff (which displays no changes) or git reset and then
> run gitk again, there is no longer that "Local uncommitted
> changes..." entry.
>
> Since it was suggested on #irc, I tried "git config --global
> core.trustctime false" but that didn't help, which I suppose was
> expected since the documentation talks about differences between
> the index and the working copy and I haven't added anything to the
> index.
>
> I can reproduce this problem with another (private) repository as
> well.
I used bisect to find which commit introduced this bug and the
result is:
7faee6b8de836904227ee98dc3d2c4c75b0ef3a1 is first bad commit
commit 7faee6b8de836904227ee98dc3d2c4c75b0ef3a1
Author: Mark Levedahl <mlevedahl@gmail.com>
Date: Mon Oct 13 00:33:31 2008 -0400
compat/cygwin.c - Use cygwin's stat if core.filemode == true
Cygwin's POSIX emulation allows use of core.filemode true, unlike native
Window's implementation of stat / lstat, and Cygwin/git users who have
configured core.filemode true in various repositories will be very
unpleasantly surprised to find that git is no longer honoring that option.
So, this patch forces use of Cygwin's stat functions if core.filemode is
set true, regardless of any other considerations.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:040000 040000 8cbed462649839a444f63c54ddc5b1a0fb5eed8e 4dab6846ae35f2c5d2971d5810c30b39278c7060 M Documentation
:040000 040000 f64d96b06609aadc586fa4312a57900c911779df cbf9743456a38bb3584e48e27d4659e8ec3b0be4 M compat
--
Hannu
^ permalink raw reply
* Re: [RFC PATCH v2] fetch-pack: log(n)-transmission find_common()
From: Nicolas Pitre @ 2008-10-28 14:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Thomas Rast, git
In-Reply-To: <7vljw9h061.fsf@gitster.siamese.dyndns.org>
On Mon, 27 Oct 2008, Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
> > Quoting Thomas Rast <trast@student.ethz.ch>:
> >
> >> Replaces the existing simple history search with a more sophisticated
> >> algorithm:
> >>
> >> 1) Walk history with exponentially increasing stride lengths; i.e.,
> >> send the 1st commit, then the 2nd after that, then the 4th after
> >> that, and so on.
> >>
> >> 2) Bisect the resulting intervals.
> >
> > Junio, may I ask what the status of this patch is? I see Nicolas responded and said "I gave this a quick try". Wasn't it a good enough review?
>
> I took the "quick try" more about "first feel in performance" and not
> "code review concentrating on correctness and trying to catch mistakes".
Exact.
FWIW, I had to back this patch out from my version as things seemed to
fall into an infinite loop of ref negotiation while fetching the Linux
kernel repository at some point. Doing a "git fetch -v -v" turned up an
endless stream of "got" and "have" lines. I was in a hurry for $work so
didn't think of preserving my local refs for reproduction of the
problem.
Sorry for not being more helpful. This is some part of git that I know
f-all about.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Linus Torvalds @ 2008-10-28 15:17 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20081028054539.GA23195@sigill.intra.peff.net>
On Tue, 28 Oct 2008, Jeff King wrote:
>
> - Does it make sense to have this _in addition_ to --decorate (since
> for any commit with a --decorate field, it would likely be the same
> as --source)? Should it be a different type of decorate instead,
> like --decorate=source or --decorate=branch?
I think they are different. People who want --source generally have other
issues than people who want --decorate, and the two do actually work
together.
In particular, think about things like "gitk", which currently can't do
_either_, but that could easily support both. Even to the point where gitk
might want to add both flags on its own, just to always get the branch and
the decorate output.
And no, they are _not_ the same. They are vehemently not the same when you
use abything but '--all', and even with --all they are different because
decorate has no problems with multiple decorations on one commit, while
source is very much a single thing per commit.
And --source really has to be just a single data field, because anything
else will almost inevitably be too expensive to be worth it.
> - Should this be triggered by the "%d" --pretty=format specifier? This
> two-liner:
>
> diff --git a/pretty.c b/pretty.c
> index f6ff312..bdaad19 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -487,6 +487,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
> const char *prefix = " (";
>
> load_ref_decorations();
> + if (commit->util)
> + printf("%s", (char *)commit->util);
> d = lookup_decoration(&name_decoration, &commit->object);
> while (d) {
> strbuf_addstr(sb, prefix);
>
> works, but:
>
> - it doesn't check revs->show_source, so is it possible that
> commit->util is being used for something else?
Indeed. You should always do the show_source check. There are different
things that use 'util', and while I don't think any of them will ever use
the format string, it's still a good idea to just make it consistent.
However:
> - using '%d' automatically turns on --decorate, so you end up with
> both the --source and --decorate values. More sensible semantics
> would be "%d turns on --decorate, unless you have done
> --decorate=<explicit format>".
As mentioned above, I think this is a non-starter. I don't think
"decorate" and "source" really have anything to do with each other, except
that they get printed out in similar ways and in the same function for the
default printout.
And quite frankly, even that was partly just a "minimal diff" thing,
although I do think that they both are "decorations", it's just that they
are very _different_ decorations.
> Alternatively, this should just be "%b" or "%S".
So yeah, I'd expect a new format specifier.
> - If you don't specify --all, you just get "HEAD" for everything.
> Which makes sense when you consider the implementation, but I think
> is probably a bit confusing for users.
I don't think it's at all confusing, for two reasons:
- you'd never ever use it manually unless you give multiple branches. Why
would you spend time to type out '--source' unless it was because you
needed to?
- for scripting, you want things consistent, even if the 'consistency' is
purely about always showing HEAD when that's the only source.
For the second case, imagine having gitk always add "--source" and
"--decorate" to the command line (the same way it always adds --parents
and --pretty=raw etc). gitk doesn't want to care how many branches you
give it as arguments, or whether you use --tags or --all. But it would
want to always parse things the same way.
No?
> Hmm. It would be nice to keep even a simple counter to get a "distance"
> from the ref and choose the one with the smallest distance
We don't have the space. The other fields on "struct commit" are already
used (indegree is used for topo sorting etc), and while we could make the
pointer itself point to a more complex structure rather than the name (one
that contains counts and possibly multiple names), that would now mean
that we'd have to make another allocation for each commit.
And that's very much against the whole point of the 'source' decoration.
It was designed to be basically zero-cost.
I could imagine doing it as not a single string: you could make it be a
pointer to a list of (alphabetically sorted) strings, and then you don't
have to make an allocation for each commit, you'd only need to do
something like
void add_source(struct commit *commit, struct strin_list *list)
{
struct string_list *old = commit->util;
if (!old) {
commit->util = list;
return;
}
if (old == list)
return;
.. do a union sort of 'old'/'list' ..
}
and I think it would be a stable algorithm (ie we'd share all normal
cases, and only have to allocate new lists in the relatively rare cases of
graphs joining), and that would be acceptable.
But the "counter" thing would not work. Not because it's expensive to
count (it's not - you just increment the counter every time you go to a
parent, and then if the parent already has a ->util entry, you replace it
if the new one has a smaller count), but because it's just expensive to do
another allocation for each commit.
(Of course, "expense" is relative. Maybe another allocation is ok, since
it would only trigger with --source.)
Linus
^ permalink raw reply
* Re: Gitk/Cygwin bug: phony local changes
From: Alex Riesen @ 2008-10-28 15:27 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <837i7s3ga4.fsf@kalahari.s2.org>
2008/10/28 Hannu Koivisto <azure@iki.fi>:
> I used bisect to find which commit introduced this bug and the
> result is:
>
> 7faee6b8de836904227ee98dc3d2c4c75b0ef3a1 is first bad commit
> commit 7faee6b8de836904227ee98dc3d2c4c75b0ef3a1
> Author: Mark Levedahl <mlevedahl@gmail.com>
> Date: Mon Oct 13 00:33:31 2008 -0400
>
> compat/cygwin.c - Use cygwin's stat if core.filemode == true
>
Could you try the patch from Junio's "Re: [PATCH] Only update the
cygwin-related configuration during state auto-setup" mail and see
if it changes anything?
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Pieter de Bie @ 2008-10-28 15:33 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0810281536360.27029@ds9.cixit.se>
On 28 okt 2008, at 15:41, Peter Krefting wrote:
> It seems to me that use of DVCS is polarising between Git, Mercurial
> and Bzr. It would be nice to have easy interoperability between the
> systems, at least as far as can be covered by the lowest common
> denominator of what they support. I would love to be able to use Git
> to
> clone a Bzr repository that I need to be able to access, since bzr is
> just different enough from Git to be annoying. Same goes for
> Mercurial.
> And I am sure that users of the other tools feel the same.
>
> Would it be possible to design a common transfer format that could be
> implemented by all three (and that would be a little smarter than
> fast-export/fast-import)?
What would you want that the fast-export/imports are lacking? I think
they are excellent tools to build some integration on.
You might want to look at my git-bzr script (http://github.com/pieter/git-bzr/tree/master
), which I created so I could use
bazaar branches easily in git. It allows you to fetch a bzr branch,
merge it in with your local work, and then push it out again:
git bzr add bzr-branch ~/bazaar/something
git bzr fetch bzr-branch
git merge bzr/bzr-branch
git bzr push bzr-branch
It's quite crude, but it's also only 100 lines or so and does what I
need. It should also be simple enough to adapt it to also incorporate
hg. When I needed the bzr integration, I looked into hg as well, but
there wasn't a hg fast-import yet. If I understand dscho correctly,
that exists now, so it should be easy enough to integrate that as well.
- Pieter
^ permalink raw reply
* Re: [PATCH 6/6] t9400, t9401: use "git cvsserver" without dash
From: Junio C Hamano @ 2008-10-28 15:57 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: git
In-Reply-To: <20081028111610.GE1682@wo.int.altlinux.org>
Thanks; will cherry-pick both.
^ permalink raw reply
* Re: Gitk/Cygwin bug: phony local changes
From: Hannu Koivisto @ 2008-10-28 16:04 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0810280827o2ccca3bfw127877782f5a0909@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> 2008/10/28 Hannu Koivisto <azure@iki.fi>:
>
>> I used bisect to find which commit introduced this bug and the
>> result is:
>>
>> 7faee6b8de836904227ee98dc3d2c4c75b0ef3a1 is first bad commit
>> commit 7faee6b8de836904227ee98dc3d2c4c75b0ef3a1
>> Author: Mark Levedahl <mlevedahl@gmail.com>
>> Date: Mon Oct 13 00:33:31 2008 -0400
>>
>> compat/cygwin.c - Use cygwin's stat if core.filemode == true
>>
>
> Could you try the patch from Junio's "Re: [PATCH] Only update the
> cygwin-related configuration during state auto-setup" mail and see
> if it changes anything?
It seems to fix the problem.
Something I forgot to mention in the previous mail: the problem
occurs whether I have core.fileMode set to true or false.
--
Hannu
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Nicolas Pitre @ 2008-10-28 15:03 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0810281536360.27029@ds9.cixit.se>
On Tue, 28 Oct 2008, Peter Krefting wrote:
> Johannes Schindelin:
>
> > While many may say that that is a half-baked solution, I actually
> > like it. Mercurial and Git are pretty similar in their concept (if
> > not in how the data is actually stored).
>
> That touches on something that I have been thinking about for a while.
>
> How difficult are the storage formats? Would it be possible, in a
> reasonable amount of work, to add support for the Mercurial protocol
> and format in "git clone", so that I could clone a Mercurial repository
> and work on it with Git, and then possibly use "git push" to possibly
> push the result back to Mercurial?
The git protocol is intimately tied to its repository storage format,
making any interoperability at the protocol level really hard. It is
probably easier to perform the clone/push operations with native tools
and do the interoperability dance locally between repositories, possibly
with some wrappers hiding all the details. In the end you could still
be doing a "git push" but the native tool is best for handling transfer
protocols. Yes, there is git-cvsserver outperforming a real CVS server,
but that's another story.
Nicolas
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-28 16:27 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Peter Harris, git
In-Reply-To: <4906C957.9010304@drmicha.warpmail.net>
Michael J Gruber wrote:
>
>> That downside is a bit disappointing. I might as well just make "git
>> remote export" simply generate a script of "git remote add" commands
>> based on the contents of .git/config, and check that script in. Then I
>> could run the script in a clone to recreate the origin's remotes.
>
> Yes, if you feel okay about running a script repeatedly which may change
> due to being versioned; rather than running a script/command which uses
> versioned input.
Either way it's a two-step process: "git pull; git remote import" vs.
"git pull; ./import-remotes.sh".
>> It also seems awkward to have an export step in the origin repository.
>> I don't really see a need for an export step (except as an artifact of
>> the above implementation).
>
> I had the impression that you want to configure as much as possible on
> the "central", and have clones follow automatically. It's very likely
> that you want your clones to see only a subset of central's remotes.
> Both (individually) imply that there has to be a step on central which
> determines which (if any) central remotes appear in clones automatically.
I actually don't care to limit what the clones can see. I understand
the reasoning behind such control, but in my case it just doesn't apply.
>> It seems to me that this would be more natural if our hypothetical "git
>> remote import <X>" could just grab the remotes from repository <X> (or
>> the origin, if <X> is unspecified). I assume that would involve
>> lower-level changes than what you described, but to me it seems like the
>> more usable approach. (But then I know nothing of Git's internals, so
>> maybe this kind of change would be too much work?)
>
> Feel free to hack the protocol and remote commands... Implementing
> anything which exposes "server's" .git/config on the client without
> interaction on the server side will most probably be rejected, though.
Point taken, but I think I will start with no origin-side controls,
since I have no need for them anyway. If/when I cobble together a patch
hopefully at that point we'll be able to have a wider discussion about
such controls.
> My suggestions were meant to be a minimal effort attempt within and
> following (see submodules) current infrastructure. I guess now it's up
> to you to pick the approach you deem most appropriate in your scenario
> and follow through with it.
Many thanks for taking the time to discuss this. Now I've got to roll
up my sleeves!
(BTW, any pointers to descriptions or overviews of git's code base?)
Marc
^ permalink raw reply
* git bisect view's use of DISPLAY environment variable in Cygwin
From: Hannu Koivisto @ 2008-10-28 16:28 UTC (permalink / raw)
To: git
Greetings,
git bisect view uses gitk if DISPLAY environment variable is set
and git log otherwise. Since gitk doesn't require X server in
Cygwin, that seems like a bit questionable condition in that
environment.
I'd prefer it to use gitk unless an option given. I think an
option would be preferable (to DISPLAY= git bisect view) in Unix as
well if you have DISPLAY set but you want it to use git log.
--
Hannu
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Christian Couder @ 2008-10-28 17:15 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83wsfs1y6v.fsf@kalahari.s2.org>
Hi,
On Tue, Oct 28, 2008 at 5:28 PM, Hannu Koivisto <azure@iki.fi> wrote:
> Greetings,
>
> git bisect view uses gitk if DISPLAY environment variable is set
> and git log otherwise. Since gitk doesn't require X server in
> Cygwin, that seems like a bit questionable condition in that
> environment.
Do you know any environment variable that we could use to detect we
can use gitk in Cygwin?
In this case a patch seems trivial.
> I'd prefer it to use gitk unless an option given. I think an
> option would be preferable (to DISPLAY= git bisect view) in Unix as
> well if you have DISPLAY set but you want it to use git log.
You can use "git bisect view log" to use "git log" even if DISPLAY is set.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Linus Torvalds @ 2008-10-28 17:21 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810280755570.3386@nehalem.linux-foundation.org>
On Tue, 28 Oct 2008, Linus Torvalds wrote:
>
> I could imagine doing it as not a single string: you could make it be a
> pointer to a list of (alphabetically sorted) strings, and then you don't
> have to make an allocation for each commit, you'd only need to do
> something like
>
> void add_source(struct commit *commit, struct strin_list *list)
Actually, no. That would be wrong.
Why? Becuase we might be printing out the commit before we see it for the
second time, so if we were to print out anything but the "first reached
data", we'd now have really nasty _unreliable_ data that would actually
change depending on whether we also do things like --topo-sort and/or do
commit limiting.
So suddenly --source would have to do the full tree just to make sure that
it's reliably giving the same information, and that makes it much less
useful.
In contrast, the thing I sent out is not only really simple and has
basically zero peformance impact, but it's actually "more reliable" in
that what it gives you is meaningful and clear. It might pick one
particular name over another in random ways that depend on internal
choices and the exact order that you gave your arguments in, but it
doesn't even _try_ to claim anything else.
The source "name" is unambiguous only if there is a single source, and it
doesn't really even try to claim anything else - for other cases, it will
give answers that "make sense" but they won't necessarily be the _whole_
truth. But it won't ever be really misleading either, and it will never
cause any slowdowns.
Linus
^ permalink raw reply
* [PATCH] Plug a memleak in builtin-revert
From: Alex Riesen @ 2008-10-28 17:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Probably happened when working around git_path's problem with returned
buffer being reused.
---
builtin-revert.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index 4725540..7483a7a 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -251,7 +251,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
int i, index_fd, clean;
char *oneline, *reencoded_message = NULL;
const char *message, *encoding;
- const char *defmsg = xstrdup(git_path("MERGE_MSG"));
+ char *defmsg = xstrdup(git_path("MERGE_MSG"));
struct merge_options o;
struct tree *result, *next_tree, *base_tree, *head_tree;
static struct lock_file index_lock;
@@ -432,6 +432,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
return execv_git_cmd(args);
}
free(reencoded_message);
+ free(defmsg);
return 0;
}
--
1.6.0.3.549.gb475d
^ permalink raw reply related
* Re: [PATCH] Add mksnpath and git_snpath which allow to specify the output buffer
From: Alex Riesen @ 2008-10-28 17:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <81b0412b0810280547nf5e6834t4049e92d374926b6@mail.gmail.com>
Alex Riesen, Tue, Oct 28, 2008 13:47:21 +0100:
> 2008/10/28 Junio C Hamano <gitster@pobox.com>:
> > Alex Riesen <raa.lkml@gmail.com> writes:
> >> Maybe I should resend the patches without it, following by patches
> >> introducing git_snpath and replacing calls to git_path.
> >
> > I took the liberty of doing the first half of just that ;-)
> >
>
> Thanks. And am sorry... I did that too, and stupidly forgot to send.
> I also considered replacing xstrdup(mkpath) with a function which does
> just that (patches 8-9). Patches 1 and 2 are unrelated, will send them
> separately.
>
> FWIW now, I'm sending the patches.
Err... The builtin-revert.c hunk of path 0009 depends on the patch I
sent later: "Plug a memleak in builtin-revert". The patch removed const
in front of "char *defmsg".
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Andreas Ericsson @ 2008-10-28 17:48 UTC (permalink / raw)
To: Arne Babenhauserheide
Cc: Miklos Vajna, Jakub Narebski, git, mercurial, SLONIK.AZ
In-Reply-To: <200810272230.51683.arne_bab@web.de>
Arne Babenhauserheide wrote:
> Am Montag 27 Oktober 2008 22:07:16 schrieb Miklos Vajna:
>> IIRC the main reason git aliases can't overwrite git commands is because
>> that would break scripts relying on the output of existing git commands.
>> Given that I install such an extension, won't my script break?
>
> Since that "script" will likely be an extension which will use the core
> function instead of the UI command, it won't break.
>
> Stuff which does command line parsing can naturally break when I change the
> output. But it can also directly use the advanced features.
>
But then you're back with a single language, taking valuable freedom
away from the addon author. How many perl gurus have skipped writing
stuff for hg because it's a "python-or-bust" thing?
And please don't give me that rubbish of "but Python is obviously better
than C". Which one's true (if any) depends only on how you define "better".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Hannu Koivisto @ 2008-10-28 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <c07716ae0810281015s47741fdqec4c3bed3313bb6a@mail.gmail.com>
"Christian Couder" <christian.couder@gmail.com> writes:
> Hi,
>
> On Tue, Oct 28, 2008 at 5:28 PM, Hannu Koivisto <azure@iki.fi> wrote:
>> Greetings,
>>
>> git bisect view uses gitk if DISPLAY environment variable is set
>> and git log otherwise. Since gitk doesn't require X server in
>> Cygwin, that seems like a bit questionable condition in that
>> environment.
>
> Do you know any environment variable that we could use to detect we
> can use gitk in Cygwin?
I looked around and I believe there is no such variable. I suppose
the only case where you cannot use gitk is when the user is logged
on using ssh, telnet, psexec or similar (well, unless you use some
non-standard Tcl/Tk build which is configured to use X instead of
Windows graphics). Then again, I don't think typical Windows
programs do any checks for such situations.
So, easy fix: always use gitk unless log is specified. Harder fix:
figure out a way to test if the login session is such that
graphical applications can be run.
> You can use "git bisect view log" to use "git log" even if DISPLAY is set.
I'd rather not use undocumented functionality ;)
--
Hannu
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-28 19:11 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Miklos Vajna, Jakub Narebski, git, mercurial, SLONIK.AZ
In-Reply-To: <4907506C.8090609@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]
Am Dienstag 28 Oktober 2008 18:48:28 schrieb Andreas Ericsson:
> > Stuff which does command line parsing can naturally break when I change
> > the output. But it can also directly use the advanced features.
>
> But then you're back with a single language, taking valuable freedom
> away from the addon author.
Not really.
Extension authors just have to take care to keep their output compatible.
You can do command line parsing just like with git, but additionally you can
change the workings of the basic commands, but then you have to take care to
keep the output compatible.
For example when I wrote the group extension, I made sure that the log only
gives grouped output, when it is explicitely asked to do so, either via
--group or via the grouped_log=True setting in .hgrc.
> How many perl gurus have skipped writing
> stuff for hg because it's a "python-or-bust" thing?
How many Python people decided to write an extension for hg, because it can
very nicely be accessed via Python?
(and which one of these has the higher effect? :) )
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Miklos Vajna @ 2008-10-28 19:12 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <E026EBDF-F402-49AB-A7A8-0A0EFB513907@ai.rug.nl>
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> fast-import yet. If I understand dscho correctly, that exists now, so it
> should be easy enough to integrate that as well.
That's new to me. Theodore Ts'o once mentioned on this list that there
is a "hg fast-export" but actually he just referred to "there is a
git2hg conversion tool in hg's contrib dir" and it has nothing with
fast-import.
There is an other reference to hg fast-import:
http://www.nabble.com/cvs2git-2.1-causes-git-fast-import-to-exit-with-an-error-td16049922.html
but I found no code so far.
To sum up, I'm not so sure about a working hg fast-import is available
at the moment.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 19:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810280755570.3386@nehalem.linux-foundation.org>
On Tue, Oct 28, 2008 at 08:17:02AM -0700, Linus Torvalds wrote:
> > - Does it make sense to have this _in addition_ to --decorate (since
> > for any commit with a --decorate field, it would likely be the same
> > as --source)? Should it be a different type of decorate instead,
> > like --decorate=source or --decorate=branch?
>
> I think they are different. People who want --source generally have other
> issues than people who want --decorate, and the two do actually work
> together.
Sleeping on this and thinking about it some more, I think you are right
here, and all of the other complaints I had just go away.
I was thinking of it as "decorate commits with the likely branches they
were made on." But that's not what this is at all (though it happens to
come up with similar answers!). It's really about "show which ref, of
the refs which were requested to be shown, we started at to reach this
commit." Which is perhaps more limited, but obvoiusly is much faster to
compute.
And then the output of "git log --source HEAD" makes perfect sense, and
it makes sense not to worry about finding the "closest" ref. It is
really about annotating the traversal that you asked for.
So now my only complaint is the lack of documentation and tests. ;)
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox