* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Junio C Hamano @ 2008-07-19 0:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Daniel Barkalow
In-Reply-To: <1216366485-12201-3-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> builtin-clone.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index 643c7d4..fddf47f 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -115,7 +115,7 @@ static char *guess_dir_name(const char *repo, int is_bundle)
> if (!after_slash_or_colon)
> end = p;
> p += 7;
> - } else if (*p == '/' || *p == ':') {
> + } else if (is_dir_sep(*p) || *p == ':') {
> if (end == limit)
> end = p;
> after_slash_or_colon = 1;
Ok, but the surrounding code in this function look very suspicious.
* The variable "prefix" is actually about suffix.
* "else if" for explicit ".bundle" case look redundant; it would never
trigger, I suspect.
* Values used to increment p for "prefix" case and ".bundle" case are
inconsistent. I think the redundant one increments by the right value
(i.e. strlen(prefix)-1 is bogus).
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section
From: Junio C Hamano @ 2008-07-19 0:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080718131800.GP10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> However, I think we may want to talk about "How to tell if your merge did
>> not even touch your index nor working tree" somewhere in the manual.
>> "When there are conflicts, these things happen" part talks about how to
>> resolve conflicts, but when merge refuses to avoid losing local changes,
>> the instruction in that part does not apply.
>
> I'm not sure if this is worth pondering about? The action would feel
> rather obvious to me - get rid of the local changes somehow, either
> committing them or stashing them or wiping them out. Is that worth
> elaborating, or is there more to it?
Oh, the necessary action is obvious. That's not the issue. You either
forget about the merge and in that case your index and working tree is
intact and you can keep going. Or stash to merge first.
But what I was wondering was if we have given the users enough clues to
tell if the above is the right action. If merge started and conflicted,
then forgetting about it and keep going is _not_ the right thing, and the
user needs to be able to tell these two very distinct cases apart.
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Jakub Narebski @ 2008-07-19 0:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <20080718165407.GU10151@machine.or.cz>
Petr Baudis wrote:
> Jakub Narebski wrote:
>> [...]
>> $r = Git::Repo->new(<git_dir>);
>> $r->output_pipe('ls_tree', 'HEAD');
>> [...]
>> $nb = Git::Repo::NonBare->new(<git_dir>[, <working_area>]);
>> $nb->output_pipe('ls-files');
>>
>>
>> How can it be done with minimal effort, unfortunately I don't know...
>
> Well, this interface is almost identical to what I delineated, except
> that I have the extra ->cmd-> step there. But maybe, we could go with
> your API and instead have Git::CommandFactory as a base of Git::Repo?
> The hierarchy would be
>
> Git::CommandFactory - provides the cmd_pipe toolkit
> |
> Git::Repo - provides repository model
> |
> Git::Repo::NonBare - additional working-copy-related methods
>
> I think I will post a sample implementation sometime over the weekend.
What I would want from the solution is an easy way to set up path
to git binary for _all_ git command calls, and for invoking command
which does not need git repository to run (like git-ls-remote).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH] Support gitlinks in fast-import/export.
From: Johannes Schindelin @ 2008-07-18 23:21 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200807182234.47363.angavrilov@gmail.com>
Hi,
On Fri, 18 Jul 2008, Alexander Gavrilov wrote:
> On Friday 18 July 2008 21:36:26 Johannes Schindelin wrote:
> > > What I'm unsure of is, should fast-export try to reuse commit
> > > marks for gitlinks where it happened to recognize the object, or
> > > always output the SHA as it is stored in the tree?
>
> > Are they commit marks? No. So they should be handled as marks, just
> > as those for blobs and trees.
> >
> > (They are commit marks in the _submodule_, but that does not matter
> > here.)
>
> Well, I was thinking of that unlikely case when the master module and
> the submodule are in the same repository and are exported together. But
> probably it is best to just output the SHA after all.
Exactly.
What you describe is a _possibility_. Requiring it would be a serious
mistake.
> > > for (i = 0; i < diff_queued_diff.nr; i++)
> > > - handle_object(diff_queued_diff.queue[i]->two->sha1);
> > > + if (!S_ISGITLINK(diff_queued_diff.queue[i]->two->mode))
> > > + handle_object(diff_queued_diff.queue[i]->two->sha1);
> >
> > Why? You do not want to export changes in the submodules?
>
> handle_object opens the sha as a blob and outputs it. As gitlinks aren't
> blobs, it won't work. And if the submodule is in a separate repository,
> there is nothing to open anyway.
So what should happen to them instead? Ignoring them?
Possible.
My earlier remark about the marks was this: you might want to mark SHA-1s
of gitlinks with a (shorter) number, but maybe that is just bullocks. At
the same time, it might be not.
> Simultaneously reading commits from the submodule repository is a whole
> different level of complexity. I'm afraid I'm not up to it yet.
Good news for you: I think it would be a serious mistake to read commits
from the submodule.
> > > else {
> > > struct object *object = lookup_object(spec->sha1);
> > > - printf("M %06o :%d %s\n", spec->mode,
> > > - get_object_mark(object), spec->path);
> > > + int mark = object ? get_object_mark(object) : 0;
> >
> > As I said, that looks wrong. Maybe we have to fake objects for the
> > gitlinks.
>
> I tried to avoid faking blobs and stick to the interface of the M
> command itself.
My point was: I do not see gitlinks handled _at all_.
I agree that they should not be handled the same as blobs, but i did not
have time to check that gitlinks are not just ignored by your patch.
Which would be wrong: you want the exported commits to contain them.
> > > @@ -1900,7 +1901,16 @@ static void file_change_m(struct branch *b)
> > > p = uq.buf;
> > > }
> > >
> > > - if (inline_data) {
> > > + if (S_ISGITLINK(mode)) {
> > > + if (inline_data)
> > > + die("Git links cannot be specified 'inline': %s",
> > > + command_buf.buf);
> > > + else if (oe) {
> > > + if (oe->type != OBJ_COMMIT)
> > > + die("Not a commit (actually a %s): %s",
> > > + typename(oe->type), command_buf.buf);
> >
> > How is that supposed to work? Do I understand correctly that you
> > require the user to construct a commit object for the gitlink? That
> > would be actively wrong.
>
> There are three forms of the M command:
>
> M mode inline some/path
> ...some data...
>
> M mode :mark some/path
>
> M mode SHA some/path
>
> For usual files the mark must be created by the 'blob' command,
> and the SHA must refer to an existing blob. This hunk makes fast-import
> require for gitlinks a commit mark instead, and accept the SHA without
> checking (as it is expected to be in another repository).
What's this commit mark thing? I hope you do not mean to ask the user to
construct a commit object in the _superproject's_ repository...
> > Oh, and your patch lacks test cases that demonstrate how you envisage
> > the whole thing to work.
>
> Ok, I'll make some tests tomorrow.
Maybe I should enhance on my point, to drive it home:
If you do _not_ include automated tests, other people have less reason to
trust that your patch does what you insist it does.
If you do not include tests, and have a sparse commit message (which you
do), people are left to guess what your patch tries to do, and do not even
have the chance to see something you wanted to work.
If you do not include tests, and your patch does something a reviewer
feels it should not to, or omits something a reviewer feels it _should_
do, there is less of an opportunity to see if this was intended: a
comprehensive test script would show what the submitter expects to
work alright.
So in a very real sense, it is advisable to write the test _first_, and
then the patch.
Not everything XP brought to this world is evil. (Oh yes, you guessed it,
I was talking about eXtreme Programming...)
Ciao,
Dscho
^ permalink raw reply
* Re: Hacks for AIX
From: Brandon Casey @ 2008-07-18 23:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Cowan, git
In-Reply-To: <7v3am9sn2p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "Chris Cowan" <chris.o.cowan@gmail.com> writes:
>> * /usr/bin/patch - really old version, doesn't do well with some
>> diff formats. I avoid using it.
>
> t4109 seems to use patch to produce expected output for the tests; we
> should ship a precomputed expected results. Do you know of any other
> places "patch" is used?
t4110 also uses patch in the same way.
-brandon
^ permalink raw reply
* Re: Addremove equivalent [was: Re: Considering teaching plumbing to users harmful]
From: Johannes Schindelin @ 2008-07-18 23:03 UTC (permalink / raw)
To: Jay Soffian; +Cc: Michael J Gruber, git
In-Reply-To: <76718490807181318o228171f9j836aaca2edb9b377@mail.gmail.com>
Hi,
On Fri, 18 Jul 2008, Jay Soffian wrote:
> On Fri, Jul 18, 2008 at 5:55 AM, Michael J Gruber
> <michaeljgruber+gmane@fastmail.fm> wrote:
> > sometimes I find my self wanting an "addremove", such as in a situation like
>
> I have the following aliased as "addremove":
>
> git ls-files -d -m -o -z --exclude-standard \
> | xargs -0 git update-index --add --remove
But that is everything, _except_ easy for newbies!!!
I still suggest "git add -u && git add .".
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Mark Levedahl @ 2008-07-18 22:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nigel Magnay, Johannes Schindelin, Git Mailing List
In-Reply-To: <20080718154959.GS10151@machine.or.cz>
Petr Baudis wrote:
> On Fri, Jul 18, 2008 at 04:09:40PM +0100, Nigel Magnay wrote:
>
> In that case you would need the "URL mappings", perhaps as a per-remote
> attribute. That is, you could configure:
>
> "When I am doing git pull fred, do git submodule update but
> apply remote.fred.subrewrite sed script on each URL before
> fetching the submodule."
>
> Still, that feels quite hackish to me, and I'm not convinced that your
> workflow cannot be adjusted so that users merge only the next-to-last
> commit of a branch instead of the last one.
>
There really are two distinct forms of submodule URL's supported by
git-submodule: absolute and relative. The first says "always go to repository x
on server y", and is the correct form for a *very* loosely coupled submodule.
However, it requires a lot of hacking to support fetching from an alternate
location.
The relative form says "go to this location *relative* to the superproject's
repository". Using this form greatly eases the use case. Basically, fred has his
tree of trees on his system, arranged exactly as they are on the main server. If
you do a git fetch "fred" into superproject, then submodule update, submodule
should be able to find the related submdodules on "fred" and get the data
relatively easily.
I actually submitted a patch series a while back that does this, but no-one on
the list cared for the use case it supported so that series died.
Mark
^ permalink raw reply
* Re: gitdm v0.10 available
From: Jakub Narebski @ 2008-07-18 22:11 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: LKML, git, Greg KH
In-Reply-To: <20080718154657.7ff0cf9e@bike.lwn.net>
Jonathan Corbet <corbet@lwn.net> writes:
> Gitdm (the "git data miner") is the tool that Greg KH and I have used
> to crank out statistics on where kernel patches come from. For the
> curious, I have (finally) put up a public repository for gitdm at:
>
> git://git.lwn.net/gitdm.git
I have added information about this tool to Git Wiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-fbb1cec362b54c74c5bbad3766f8a8f8f883af12
Please check if it is correct, and correct any mistakes (it is wiki!).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [StGit PATCH 3/5] Show full command in subprocess profiling
From: Catalin Marinas @ 2008-07-18 21:47 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080717204238.23407.47439.stgit@yoghurt>
2008/7/17 Karl Hasselström <kha@treskal.com>:
> Showing just the executable name isn't so useful now that it's always
> "git".
Yes, indeed.
--
Catalin
^ permalink raw reply
* gitdm v0.10 available
From: Jonathan Corbet @ 2008-07-18 21:46 UTC (permalink / raw)
To: LKML, git; +Cc: Greg KH
Gitdm (the "git data miner") is the tool that Greg KH and I have used
to crank out statistics on where kernel patches come from. For the
curious, I have (finally) put up a public repository for gitdm at:
git://git.lwn.net/gitdm.git
That repository is currently tagged at v0.10, for whatever that's worth.
There is a mildly redacted version of the configuration files used in
the creation of kernel statistics at:
http://lwn.net/images/gitdm/gitdm-config-2.6.26.tar.bz2
If nothing else, the domain->company mapping files should be useful for
anybody who might be interested in using gitdm on projects other than
the kernel.
Please be warned that gitdm is not a polished release of a
production-quality tool; it's something which has been made to work
just well enough for what we needed to do at any given time. Needless
to say, patches to make it better are welcome.
jon
^ permalink raw reply
* Re: [StGit PATCH 2/5] Log subproces activity to a file
From: Catalin Marinas @ 2008-07-18 21:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080717204233.23407.59842.stgit@yoghurt>
2008/7/17 Karl Hasselström <kha@treskal.com>:
> If the user sets $STGIT_SUBPROCESS_LOG to a log mode followed by a
> colon and a file name, append the log to that file instead of writing
> it to stdout.
OK.
--
Catalin
^ permalink raw reply
* Re: [StGit PATCH] Add some performance testing scripts
From: Catalin Marinas @ 2008-07-18 21:41 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080716193549.3467.13072.stgit@yoghurt>
2008/7/16 Karl Hasselström <kha@treskal.com>:
> find_patchbomb.py: Given a git repo, finds the longest linear sequence
> of commits. Useful for testing StGit on a real repository.
>
> setup.sh: Creates two test repositories, one synthetic and one based
> on the Linux kernel repo, with strategically placed tags.
>
> create_synthetic_repo.py: Helper script for setup.sh; it produces
> output that is to be fed to git fast-import.
>
> perftest.py: Runs one of a (small) number of hard-coded performance
> tests against a copy of one of the repos created by setup.sh. The
> initial testcases all involve uncommitting a large number of patches
> and then rebasing them.
Looks good. Thanks.
--
Catalin
^ permalink raw reply
* Re: [RFC PATCH] Support gitlinks in fast-import/export.
From: Shawn O. Pearce @ 2008-07-18 20:43 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200807182103.37272.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> Currently fast-import/export cannot be used for
> repositories with submodules. This patch extends
> the relevant programs to make them correctly
> process gitlinks.
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> I noticed that fast-export & fast-import cannot work with
> repositories using submodules: import complains about
> an invalid mode, and export fails while trying to open the SHA
> as a blob.
>
> As I didn't see any particular reason for it to be so, I tried to
> implement support for gitlinks.
>
> What I'm unsure of is, should fast-export try to reuse commit
> marks for gitlinks where it happened to recognize the object,
> or always output the SHA as it is stored in the tree?
Its unlikely that the commit objects are in the repository the
export is running in, so its unlikely you can use a mark. Its
fine to just always output the SHA-1 I think.
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH 17/28] Support automatic command line parsing for TextBuiltin subclasses
From: Shawn O. Pearce @ 2008-07-18 20:38 UTC (permalink / raw)
To: Florian KKKberle; +Cc: Robin Rosenberg, Marek Zawirski, git
In-Reply-To: <4880E880.1010403@web.de>
Florian KKKberle <FloriansKarten@web.de> wrote:
> I had a short look at the files and noticed that the inner "if (help) {"
> is unnecessary:
>
> + if (help) {
> + System.err.print("jgit ");
> + System.err.print(commandName);
> + clp.printSingleLineUsage(System.err);
> + System.err.println();
> +
> + if (help) {
Gaaah. Good catch, thanks. I copied and pasted that block from the
global option parser to the per-command parser, and then refactored
it a little and missed removing this unnecessary inner if test.
I'll fix with a rebase.
--
Shawn.
^ permalink raw reply
* Re: Addremove equivalent [was: Re: Considering teaching plumbing to users harmful]
From: Jay Soffian @ 2008-07-18 20:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48806897.1080404@fastmail.fm>
On Fri, Jul 18, 2008 at 5:55 AM, Michael J Gruber
<michaeljgruber+gmane@fastmail.fm> wrote:
> sometimes I find my self wanting an "addremove", such as in a situation like
I have the following aliased as "addremove":
git ls-files -d -m -o -z --exclude-standard \
| xargs -0 git update-index --add --remove
http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.html
j.
^ permalink raw reply
* Re: Suggestion: doc restructuring
From: Junio C Hamano @ 2008-07-18 19:50 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Michael J Gruber, git
In-Reply-To: <4880E041.8070001@freescale.com>
Jon Loeliger <jdl@freescale.com> writes:
> The current sub-setting and organization is painful because
> it doesn't have a comprehensive, linear, alphabetized list
> of commands from which to select the real man page. I never
> know which "section" to find a given command. Is it an
> Ancillary "manipulator" command? Or maybe just a "Manipulation"
> command, or maybe an "Interrogation" command? A "Helper"?
>
> I always have to painfully search the page for it instead.
When you are on-line (like your case to read kernel.org webpage), it is
rather easy with ^F (or whatever browser you use lets you search).
But I do agree with you that on printed medium we would want a nice
alphabetized list somewhere.
^ permalink raw reply
* Re: [JGIT PATCH 17/28] Support automatic command line parsing for TextBuiltin subclasses
From: Florian Köberle @ 2008-07-18 19:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, Marek Zawirski, git
Hi Shawn
to use args4j was really a great idea. I had a patch, implementing
something similar to args4j in my repository, but using a library is
always better. *thumb up*
I had a short look at the files and noticed that the inner "if (help) {"
is unnecessary:
+ if (help) {
+ System.err.print("jgit ");
+ System.err.print(commandName);
+ clp.printSingleLineUsage(System.err);
+ System.err.println();
+
+ if (help) {
+ System.err.println();
+ clp.printUsage(System.err);
+ System.err.println();
+ }
+ System.exit(1);
+ }
Also a cool function which you may want to use is:
public <U> Class<? extends U> asSubclass(Class<U> clazz)
With that method of Class<?> you can do the cast before you actually
create the object.
You could for example make use of them in SubcommandHandler:
l. 124 cmd = (TextBuiltin) cons.newInstance();
Best regards,
Florian Köberle
^ permalink raw reply
* Re: [StGit PATCH] Test that we can add a new file to a non-topmost patch with refresh -p
From: Karl Hasselström @ 2008-07-18 19:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, git
In-Reply-To: <9e4733910807181045mb19ab1dxaaa76696db294ddf@mail.gmail.com>
On 2008-07-18 13:45:41 -0400, Jon Smirl wrote:
> It's no big deal to me, it is easy to work around. But it did take
> me a while to notice that the add was missing.
Ah, OK, good.
> When is the refresh rewrite going to be ready for prime time?
It depends on the stack log stuff, but that is actually kind of close
to being ready now. It just needs support for hidden patches.
No time estimate, sorry -- vacation time's coming up, so I can't
really predict how much time I'll spend hacking.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* RE: Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]
From: Craig L. Ching @ 2008-07-18 18:52 UTC (permalink / raw)
To: Jon Loeliger, Michael J Gruber; +Cc: git
In-Reply-To: <4880E041.8070001@freescale.com>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Jon Loeliger
> Sent: Friday, July 18, 2008 1:26 PM
> To: Michael J Gruber
> Cc: git@vger.kernel.org
> Subject: Re: Suggestion: doc restructuring [was: Re:
> Considering teaching plumbing to users harmful]
>
> I always have to painfully search the page for it instead.
>
I don't want to complain too loudly because I don't think I have any
good solutions, maybe yours is a good one, having an alphabetized list
of commands. What I wanted to second, though, was that I too use the
browser search for all of the Git pages and that indicates that
*something* isn't optimal.
One easy thing I could suggest, and I'd be willing to try submitting
some patches if people agreed it's a valuable change (at least that's
something I think I could handle contributing for now ;-) ) is that when
you hit the "Documentation" link off the main page, instead of going
straight to the Man page, maybe it should go to a page that clearly has
the options that people are looking for. E.g. a link to the tutorial, a
link to the man page, a link to the Git User's manual, a link to the
FAQ, a link to the "Git for SVN Users" page, etc. The way it is now,
once you're used to the html rendered man page, it's not hard, but I do
think it's not the most newbie friendly way to navigate the
documentation atm. Or maybe just feature those links more prominently
at the top of the man page so they're dead easy to spot. Just my $0.02.
If someone definitively says what should be done, I'd be willing to give
it a shot.
> I'm not saying get rid of the Categorical organization.
> I am saying, we need a first-page with a straight,
> alphabetized command index somewhere easy and located conveniently.
>
> Thanks for listening,
> jdl
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Cheers,
Craig
^ permalink raw reply
* Re: [RFC PATCH] Support gitlinks in fast-import/export.
From: Alexander Gavrilov @ 2008-07-18 18:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807181810400.8986@racer>
Hello,
On Friday 18 July 2008 21:36:26 Johannes Schindelin wrote:
> > What I'm unsure of is, should fast-export try to reuse commit
> > marks for gitlinks where it happened to recognize the object,
> > or always output the SHA as it is stored in the tree?
> Are they commit marks? No. So they should be handled as marks, just as
> those for blobs and trees.
>
> (They are commit marks in the _submodule_, but that does not matter here.)
Well, I was thinking of that unlikely case when the master module and the submodule
are in the same repository and are exported together. But probably it is best to just
output the SHA after all.
> > for (i = 0; i < diff_queued_diff.nr; i++)
> > - handle_object(diff_queued_diff.queue[i]->two->sha1);
> > + if (!S_ISGITLINK(diff_queued_diff.queue[i]->two->mode))
> > + handle_object(diff_queued_diff.queue[i]->two->sha1);
>
> Why? You do not want to export changes in the submodules?
handle_object opens the sha as a blob and outputs it. As gitlinks aren't blobs, it won't work.
And if the submodule is in a separate repository, there is nothing to open anyway.
Simultaneously reading commits from the submodule repository is a whole different level
of complexity. I'm afraid I'm not up to it yet.
> > diff --git a/builtin-fast-export.c b/builtin-fast-export.c
> > index d0a462f..14b1549 100644
> > --- a/builtin-fast-export.c
> > +++ b/builtin-fast-export.c
> > @@ -123,8 +123,19 @@ static void show_filemodify(struct diff_queue_struct *q,
> > printf("D %s\n", spec->path);
> > else {
> > struct object *object = lookup_object(spec->sha1);
> > - printf("M %06o :%d %s\n", spec->mode,
> > - get_object_mark(object), spec->path);
> > + int mark = object ? get_object_mark(object) : 0;
>
> As I said, that looks wrong. Maybe we have to fake objects for the
> gitlinks.
I tried to avoid faking blobs and stick to the interface of the M command itself.
> > @@ -1900,7 +1901,16 @@ static void file_change_m(struct branch *b)
> > p = uq.buf;
> > }
> >
> > - if (inline_data) {
> > + if (S_ISGITLINK(mode)) {
> > + if (inline_data)
> > + die("Git links cannot be specified 'inline': %s",
> > + command_buf.buf);
> > + else if (oe) {
> > + if (oe->type != OBJ_COMMIT)
> > + die("Not a commit (actually a %s): %s",
> > + typename(oe->type), command_buf.buf);
>
> How is that supposed to work? Do I understand correctly that you require
> the user to construct a commit object for the gitlink? That would be
> actively wrong.
There are three forms of the M command:
M mode inline some/path
...some data...
M mode :mark some/path
M mode SHA some/path
For usual files the mark must be created by the 'blob' command,
and the SHA must refer to an existing blob. This hunk makes fast-import
require for gitlinks a commit mark instead, and accept the SHA without
checking (as it is expected to be in another repository).
> Oh, and your patch lacks test cases that demonstrate how you envisage the
> whole thing to work.
Ok, I'll make some tests tomorrow. For now, this is an example of output from
my test repository:
...
blob
mark :16
data 41
[submodule "sub"]
path = sub
url = sub
commit refs/heads/master
mark :17
author Alexander Gavrilov <angavrilov@gmail.com> 1216360728 +0400
committer Alexander Gavrilov <angavrilov@gmail.com> 1216360728 +0400
data 4
sub
from :15
M 100644 :16 .gitmodules
M 160000 d6317bc6e2597bf74ae199514a54e25775b0d20d sub
Alexander
^ permalink raw reply
* Re: Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]
From: Jon Loeliger @ 2008-07-18 18:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48806D03.30603@fastmail.fm>
Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 16.07.2008 19:21:
> ...
>>
>> Am I the only one who deems teaching plumbing to users ("I like it
>> raw! So I teach it the same way!") harmful?
>>
>> Ciao,
>> Dscho "who is sad"
>
> In an attempt at making not only Dscho happier I suggest a restructuring
> of the man pages in the following way:
>
> In each man page, put a note which says something like:
> "This is part of linkgit:gitplumbing[7]." and the like
> It should be in a prominent place, such as the last line of "DESCRIPTION".
>
> gitplumbing[7] etc. pages should contain:
> - a definition of the respective term together with appropriate usage
> advice (regular use/scripting..., "Let there be dragons.")
> - a list of commands like we have in git[1] right now
>
> With the current situation, people don't look at git[1] in order to find
> out what they're supposed to use. It's too long anyways, and could link
> the above pages instead.
>
> If there's enough interest/agreement I'd come up with a refactoring patch.
>
> Michael
I'd like to throw my beef with the main Git man page
out there for consideration as well...
When I hit the man page, which I do on line quite frequently,
I usually use it as an index to get to the real, current man
page for a particular command. (I am at git.kernel.org for
other reasons all the time, so it is convenient.)
The current sub-setting and organization is painful because
it doesn't have a comprehensive, linear, alphabetized list
of commands from which to select the real man page. I never
know which "section" to find a given command. Is it an
Ancillary "manipulator" command? Or maybe just a "Manipulation"
command, or maybe an "Interrogation" command? A "Helper"?
I always have to painfully search the page for it instead.
I'm not saying get rid of the Categorical organization.
I am saying, we need a first-page with a straight, alphabetized
command index somewhere easy and located conveniently.
Thanks for listening,
jdl
^ permalink raw reply
* Re: git-svn: Trouble after project has moved in svn
From: Jukka Zitting @ 2008-07-18 18:27 UTC (permalink / raw)
To: git
In-Reply-To: <510143ac0807161512w44a612bcndc53713639b0b70a@mail.gmail.com>
Hi,
On Thu, Jul 17, 2008 at 1:12 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Somewhat related to the recent thread about Apache Synapse, I'm having
> trouble making a git-svn clone of a project that has been moved around
> in a Subversion repository.
Ah, silly me, my test script was broken. Thanks to Michael J. Gruber
for pointing out that I should have used created the tags using svn
URLs instead of working copy path or at least done an "svn update"
before tagging. After fixing my test script the git-svn result was
exactly as I was hoping to see.
I think that covers my last barrier for creating experimental git
mirrors of various Apache codebases. Check out
http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/ for
more on git experiments at Apache.
BR,
Jukka Zitting
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Jeff King @ 2008-07-18 18:26 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48805207.80504@op5.se>
On Fri, Jul 18, 2008 at 10:19:19AM +0200, Andreas Ericsson wrote:
> In addition, I'd recommend setting
> color.branch=auto
> color.diff=auto
> color.pager=true
> color.status=true
> before starting the "course". It makes the learning experience a whole
> lot nicer.
You might be interested in the "color.ui" config option.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Johannes Schindelin @ 2008-07-18 18:23 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Petr Baudis, Jakub Narebski, git, John Hawley
In-Reply-To: <4880DC6C.7090708@gmail.com>
Hi,
On Fri, 18 Jul 2008, Lea Wiemann wrote:
> Lea: Here's a Perl API that fell out of my gitweb development for free.
> Petr: I want a pony with the API!
> Lea: But I don't have a pony. Can we please just go with the Perl API
> as a start, even if I don't supply ponies with it?
Johannes: *mumbles* no ponies? *mumbles further* Them cowboy coders keep
the ponies for themselves, eh? *mumbles and gets something to eat*
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Petr Baudis @ 2008-07-18 18:19 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Jakub Narebski, git, John Hawley
In-Reply-To: <4880DC6C.7090708@gmail.com>
On Fri, Jul 18, 2008 at 08:09:48PM +0200, Lea Wiemann wrote:
> Also, gitweb isn't using cmd_output because it needs a pipe interface,
> but because it needs a caching layer in between -- most applications
> would do just fine with open calls.
One of the points of the API is to abstract these out.
> > As I said, majority of Git API usage is actually the pipe API. So we
> > should figure out how to provide it. I agree that it's not immediately
> > within your scope, but you are introducing new Perl API and this just
> > needs to be embedded somewhere there consistently.
>
> Sure, but pleeeease not as part of this patch series! :-) Look, our
> conversation is going something like this:
>
> Lea: Here's a Perl API that fell out of my gitweb development for free.
> Petr: I want a pony with the API!
> Lea: But I don't have a pony. Can we please just go with the Perl API
> as a start, even if I don't supply ponies with it?
>
> (Cf. the very cute <http://c2.com/cgi/wiki?IwantaPony>.)
I'm fine with that, as long as the version that enters into master will
have a pony so that we stay with a single pony within the codebase in
the end, not two ponies with differently shaped saddles.
But as I said, I'm going to work on that.
> >> If you're getting a SHA1 through the user-interface, check its existence
> >> with get_sha1 before passing it to the constructor.
> >
> > But that's an expensive operation, you need extra Git exec for this,
>
> For the gazillionth time in this thread, there is no extra exec. It's a
> write to a bidirectional cat-file --batch-check pipe. It's not
> expensive. Really. ;-)
But the API is still obnoxiously elaborate, as I complained in another
mail.
> >> I have resolving code in gitweb's git_get_sha1_or_die
> >
> > The thing that concerns me about this is that this might show that your
> > approach to error handling is not flexible enough for some real-world
> > usage and this might be a design mistake - is that not so?
>
> I don't think so; the error handling is fine. Given that I want
> fine-granular error reporting for gitweb, there *needs* to be a
> git_get_sha1_or_die function; you can't move that into the API.
Wait, this doesn't compute here. The error handling is fine, but it is
actually not fine for gitweb. Can't we make it fine for everyone?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ 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