* 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
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Randal L. Schwartz @ 2008-10-28 19:16 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Arne Babenhauserheide, Miklos Vajna, Jakub Narebski, git,
mercurial, SLONIK.AZ
In-Reply-To: <4907506C.8090609@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
Andreas> And please don't give me that rubbish of "but Python is obviously
Andreas> better than C". Which one's true (if any) depends only on how you
Andreas> define "better".
But any way you define it, Perl is "better" than either of those!
:-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: [RFC PATCH v2] fetch-pack: log(n)-transmission find_common()
From: Thomas Rast @ 2008-10-28 19:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <alpine.LFD.2.00.0810281034500.13034@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
Nicolas Pitre wrote:
>
> 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.
Ah. Thanks for the report, though having a test case would be great.
I've been running it without problems since I completed v2 more than a
month ago, so I don't expect it to be an obvious mistake.
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: SZEDER Gábor @ 2008-10-28 19:38 UTC (permalink / raw)
To: Arne Babenhauserheide
Cc: Andreas Ericsson, Miklos Vajna, Jakub Narebski, git, mercurial,
SLONIK.AZ
In-Reply-To: <200810282011.40647.arne_bab@web.de>
On Tue, Oct 28, 2008 at 08:11:36PM +0100, Arne Babenhauserheide wrote:
> > 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 wouldn't they contribute at all, if there would be hg bindings for
other programming languages, would they?
Best,
Gábor
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 19:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028131116.GA8272@artemis.googlewifi.com>
On Tue, Oct 28, 2008 at 02:11:16PM +0100, Pierre Habouzit wrote:
> 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
I think we are both wrong, since it's "git describe --contains". ;)
But yes, that was what I meant.
> 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.:
Hmm. Why a date-based hack to see what's on the topic branch? Why not
just give an option to walk the graph twice, giving name-rev style
annotations, and just let it be slow. People will mostly look at it by
specifying just their topic branches anyway. IOW:
git log ^origin/master my/topic1 my/topic2 my/topic3
and by virtue of the fact that you are vastly limiting the size of the
tree, it won't actually end up too slow. So you haven't said so much
"these are my topic branches" as "I am just not interested in things
that are already upstream."
Or maybe I'm misunderstanding something here:
> 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.
When you say "heads of topic branches" do you mean we actually have the
topic branches? Or do you mean you want to crawl next, pulling the names
of the topic branches from the merge messages?
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 19:53 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028194642.GB752@sigill.intra.peff.net>
On Tue, Oct 28, 2008 at 03:46:43PM -0400, Jeff King wrote:
>
> Hmm. Why a date-based hack to see what's on the topic branch? Why not
> just give an option to walk the graph twice, giving name-rev style
> annotations, and just let it be slow. People will mostly look at it by
> specifying just their topic branches anyway. IOW:
>
> git log ^origin/master my/topic1 my/topic2 my/topic3
And obviously you could split the "these are the commits to annotate"
specification from "these are the commits to show". But I actually think
in practice most users would want those to be the same.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Pierre Habouzit @ 2008-10-28 20:09 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028194642.GB752@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
On Tue, Oct 28, 2008 at 07:46:43PM +0000, Jeff King wrote:
> On Tue, Oct 28, 2008 at 02:11:16PM +0100, Pierre Habouzit wrote:
> > 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.:
>
> Hmm. Why a date-based hack to see what's on the topic branch? Why not
> just give an option to walk the graph twice,
it serves the purpose to not walk the graph twice actually, but indeed
twice is not _that_ bad.
> giving name-rev style annotations, and just let it be slow. People
> will mostly look at it by specifying just their topic branches anyway.
> IOW:
>
> git log ^origin/master my/topic1 my/topic2 my/topic3
>
> and by virtue of the fact that you are vastly limiting the size of the
> tree, it won't actually end up too slow. So you haven't said so much
> "these are my topic branches" as "I am just not interested in things
> that are already upstream."
Well, I was just thinking quickly during jetlag-induced insomnia. I
don't really care about the issue that much actually.
--
·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: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 20:27 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028200901.GA2894@artemis.mtv.corp.google.com>
On Tue, Oct 28, 2008 at 09:09:02PM +0100, Pierre Habouzit wrote:
> > Hmm. Why a date-based hack to see what's on the topic branch? Why not
> > just give an option to walk the graph twice,
>
> it serves the purpose to not walk the graph twice actually, but indeed
> twice is not _that_ bad.
Sure, and that is reasonable. But I think the real goal is "give this
information in a not-painfully slow manner". So if we can do it by
walking a smaller graph twice, I think that is OK, too.
> Well, I was just thinking quickly during jetlag-induced insomnia. I
> don't really care about the issue that much actually.
Heh. I have to admit I don't care enough to work on this personally,
either. I just _thought_ Linus was working on it, but I think what he is
doing is subtly different, and our discussion has diverged to something
that, if it ever came to pass, would be a separate feature.
-Peff
^ permalink raw reply
* [StGit PATCH] Tutorial: Importing patches
From: Karl Hasselström @ 2008-10-28 20:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 89 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 2808462..283b358 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -621,7 +621,94 @@ get rid of such empty patches if you don't want them hanging around:
Importing patches
-----------------
-TODO:: import, ...
+While you are busy producing patches, there's hopefully someone -- the
+'maintainer' -- at the other end who recieves them and 'applies' them
+to her Git tree, which is then published for all (or parts of) the
+world to see.
+
+It's perfectly fine for this person to not have the foggiest idea what
+StGit is. In that case, she'll probably apply your patches with
+something like +git am+, and everything will just work, exactly as if
+you'd used Git to send those patches. But she might be an StGit user
+too, in which case she might use stglink:import[].
+
+There are basically four kinds if stuff you can import with
+stglink:import[]:
+
+ 1. A patch in a file.
+
+ 2. Several files containing one patch each, and a 'series' file
+ listing those other files in the correct order.
+
+ 3. An e-mail containing a single patch.
+
+ 4. A mailbox file (in standard Unix +mbox+ format) containing
+ multiple e-mails with one patch in each.
+
+
+Importing a plain patch
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Importing a plain patch, such as produced by e.g. GNU +diff+, +git
+diff+, +git show+, stglink:diff[], or stglink:show[], is very easy.
+Just say
+
+ $ stg import my-patch
+
+and you'll have a new patch at the top of your stack.
+
+If you don't give a file name on the command line, stglink:import[]
+will read the patch from its standard input -- in other words, you can
+pipe a patch to it directly from the command that produces it.
+
+By default, the new patch's name will be taken from the file name, and
+its commit message and author info will be taken from the beginning of
+the patch, if they are there. However, there are command line switches
+to override all of these things; see the man page for details.
+
+
+Importing several patches at once
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some programs -- among them stglink:export[] -- will create a bunch of
+files with one patch in each, and a 'series' file (often called
++series+) listing the other files in the correct order. Give
++$$--series$$+ and the name of the series file to stglink:import[],
+and it will import all the patches for you, in the correct order.
+
+
+Importing a patch from an e-mail
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Importing a patch from an e-mail is simple too:
+
+ $ stg import --mail my-mail
+
+The e-mail should be in standard Git mail format (which is what e.g.
+stglink:mail[] produces) -- that is, with the patch in-line in the
+mail, not attached. The authorship info is taken from the mail
+headers, and the commit message is read from the 'Subject:' line and
+the mail body.
+
+If you don't give a file name, the mail will be read from the standard
+input. This means that, if your mail reader supports it, you can pipe
+a mail directly to +stg import $$--mail$$+ and the patch will be
+applied.
+
+
+Importing a mailbox full of patches
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Finally, in case importing one patch at a time is too much work,
+stglink:import[] also accepts an entire Unix +mbox+-format mailbox,
+either on the command line or on its standard input; just use the
++$$--mbox$$+ flag. Each mail should contain one patch, and is imported
+just like with +$$--mail$$+.
+
+Mailboxes full of patches are produced by e.g. stglink:mail[] with the
++$$--mbox$$+ flag, but most mail readers can produce them too, meaning
+that you can copy all the patch mails you want to apply to a separate
+mailbox, and then import them all in one go.
Other stuff that needs to be placed somewhere
^ permalink raw reply related
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Christian Couder @ 2008-10-28 19:13 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83skqg1uc9.fsf@kalahari.s2.org>
On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
> "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.
We need at least a way to detect we are under Cygwin, because we won't
change the current behavior for all platforms.
Is checking for the CYGWIN environment variable enough?
> 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 ;)
In this case you can use any "git log" option after "git bisect view"
(for example: git bisect view -p).
Regards,
Christian.
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Miklos Vajna @ 2008-10-28 21:10 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <20081028191234.GS24201@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> To sum up, I'm not so sure about a working hg fast-import is available
> at the moment.
I wrote too fast.
There is a minimal implementation here:
http://hg.opensource.lshift.net/hg-fastimport/
(I haven't tried it yet myself.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: error pushing stash ?
From: Jeff King @ 2008-10-28 21:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Bryson, git
In-Reply-To: <20081007004051.GA18889@spearce.org>
On Mon, Oct 06, 2008 at 05:40:51PM -0700, Shawn O. Pearce wrote:
> > ! [remote rejected] refs/stash -> refs/stash (funny refname)
> > error: failed to push some refs to '/users/dbryson/backup/janus.git/'
>
> refs/stash is a funny refname because it contains only 1 '/'.
> Normally a valid ref has at least 2 '/', e.g. refs/heads/8654 or
> refs/tags/v1.0.
Since no version of receive-pack accepts these "funny refs", perhaps we
should mirror the check when considering the list of refs to send. IOW,
don't even make them eligible for matching or mirroring. Patch is below.
> Naming the stash refs/stash was perhaps funny in the first place
> since it cannot be moved about on the transport protocol, but then
> again the bulk of the stash data is actually in the reflog for the
> stash (and not the stash ref itself) so there is basically no point
> in pushing or fetching a stash directly.
I agree there is not much point in pushing it, since the useful bit is
in the reflog. So perhaps a "funny" refname is a good place to put it,
since it easily tells us that it is not a useful thing to push.
---
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index bbf6e0a..298bd71 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -140,7 +140,13 @@ static struct ref *remote_refs, **remote_tail;
static int one_local_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
struct ref *ref;
- int len = strlen(refname) + 1;
+ int len;
+
+ /* we already know it starts with refs/ to get here */
+ if (check_ref_format(refname + 5))
+ return 0;
+
+ len = strlen(refname) + 1;
ref = xcalloc(1, sizeof(*ref) + len);
hashcpy(ref->new_sha1, sha1);
memcpy(ref->name, refname, len);
^ permalink raw reply related
* Re: error pushing stash ?
From: Jeff King @ 2008-10-28 21:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Bryson, git
In-Reply-To: <20081028211755.GA8074@sigill.intra.peff.net>
On Tue, Oct 28, 2008 at 05:17:55PM -0400, Jeff King wrote:
> Since no version of receive-pack accepts these "funny refs", perhaps we
> should mirror the check when considering the list of refs to send. IOW,
> don't even make them eligible for matching or mirroring. Patch is below.
> [...]
> + /* we already know it starts with refs/ to get here */
> + if (check_ref_format(refname + 5))
> + return 0;
It occurs to me that since I didn't give a good commit message, and
since I replied to a several-weeks-old message, this might be confusing.
But what I am suggesting is that git-push should not bother trying to
send something that it knows git-receive-pack will refuse. So this check
goes into builtin-send-pack.c, and is an exact mirror of the one in
builtin-receive-pack.c:
$ sed -n 177,181p builtin-receive-pack.c
/* only refs/... are allowed */
if (prefixcmp(name, "refs/") || check_ref_format(name + 5)) {
error("refusing to create funny ref '%s' remotely", name);
return "funny refname";
}
-Peff
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Theodore Tso @ 2008-10-28 21:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Pieter de Bie, Peter Krefting, Git Mailing List
In-Reply-To: <20081028191234.GS24201@genesis.frugalware.org>
On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna wrote:
> 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.
The code I was referring to was called hg-fast-export, which is part
of the "fast export" tools that front-end into git fast-import. The
git repository can be found here:
http://repo.or.cz/w/fast-export.git
git://repo.or.cz/fast-export.git
I ended up using a very customized version of that script to convert
the hg e2fsprogs repository to git.
In the past I've looked at the possibility of creating a
bi-directional, incremental gateway between hg and git repositories.
The main thing which makes this difficult is that hg stores tags
in-band inside the change-controlled .hgtags file. This means that if
you cut a release, tag it, and then create a commit to further modify
the repository, the new commit is descended from the tag commit,
whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
but not part of the revision history.
I think the git method is much more sane, but what it means is that
topologically, the commit tree for git and hg can never be identical.
It also means that if you add a tag to a git tree after making several
commits on that branch, how you reflect that in the hg repository is
highly problematic. Do you rewrite the branch? Do you add the tag
later on, disturbing the parent-child relationship of later commits?
How do you keep track of when a tag hg repository topology if you are
trying to maintain a bidirectional mapping between commits?
It's not impossible, but it makes it much more difficult, since in the
hg world, tag commits can be inserted between arbitrary commits. This
also means that if you want to create a bidrectional gateway between
hg and git, it has to be a single gateway so it can keep track of this
state information. If you try to have multiple gateways they would
need to synchronize on when a tag entered the hg universe, and with
what commit ID (and what timestamp).
- Ted
^ 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