* 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
* Re: [PATCH] api-run-command.txt: typofix
From: Johannes Sixt @ 2008-07-18 18:12 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano
In-Reply-To: <1216338835-10627-1-git-send-email-s-beyer@gmx.net>
On Freitag, 18. Juli 2008, Stephan Beyer wrote:
> -`run_command_v_opt`, `run_command_v_opt_dir`, `run_command_v_opt_cd_env`::
> +`run_command_v_opt`, `run_command_v_opt_cd`, `run_command_v_opt_cd_env`::
Correct! Thanks.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Lea Wiemann @ 2008-07-18 18:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git, John Hawley
In-Reply-To: <20080718164828.GT10151@machine.or.cz>
Petr Baudis wrote:
> [$repo->_cmd_output:]
>
> we _need_ such a wrapper _publically_, because it tends to be
> actually the main use-case of Git.pm,
Well, sure, I happen to not be convinced, but it *may* be useful. The
point I'm trying to make is that it's not part of what I'm writing here.
> as part of your gitweb migration to Git::Repo, you will temporarily
> introduce calls to _cmd_output(), the "internal" API. :-) Sure, it's
> only temporary, but many won't have the luxury to adjust the Git::Repo
> API to provide all the operations they need, and ultimately they will
> need to defer to the pipe interface.
Yup, and I'm actually fine with that. (I'll probably alias _cmd_output
to cmd_output in gitweb, just to make it clear that it is, for the
purpose of gitweb, a *supported* mode of operation.) If the
Git::Repo::_cmd_output API goes away, you'll have to insert a few lines
of code in gitweb, but that's it. Really, no big deal.
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.
> 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>.)
>> 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. ;-)
>> 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.
-- Lea
^ permalink raw reply
* Re: [StGit PATCH] Test that we can add a new file to a non-topmost patch with refresh -p
From: Jon Smirl @ 2008-07-18 17:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20080718180109.GA14825@diana.vm.bytemark.co.uk>
On 7/18/08, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-07-18 19:03:06 +0200, Karl Hasselström wrote:
>
> > We currently can't -- this is bug 12038, found by Jon Smirl. See
> >
> > https://gna.org/bugs/index.php?12038
>
> OK, the problem is that to pop the patches on top of the one we are to
> refresh, we call pop_patch(keep = True). This in turn calls
> git.switch(keep = True), which resets the index (but is careful to not
> touch the worktree).
>
> I'm not quite sure how to fix this in a simple way -- the code simply
> assumes that the index contains nothing of interest. And since I
> already have a rewrite of refresh that handles this and a handful of
> other cases that the old code does not, I'm kind of disinclined to
> undertake a larger restructuring of the code.
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.
When is the refresh rewrite going to be ready for prime time?
>
> Catalin, what do you think?
>
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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 18:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Jon Smirl
In-Reply-To: <20080718170225.10086.17504.stgit@yoghurt>
On 2008-07-18 19:03:06 +0200, Karl Hasselström wrote:
> We currently can't -- this is bug 12038, found by Jon Smirl. See
>
> https://gna.org/bugs/index.php?12038
OK, the problem is that to pop the patches on top of the one we are to
refresh, we call pop_patch(keep = True). This in turn calls
git.switch(keep = True), which resets the index (but is careful to not
touch the worktree).
I'm not quite sure how to fix this in a simple way -- the code simply
assumes that the index contains nothing of interest. And since I
already have a rewrite of refresh that handles this and a handful of
other cases that the old code does not, I'm kind of disinclined to
undertake a larger restructuring of the code.
Catalin, what do you think?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC PATCH] Support gitlinks in fast-import/export.
From: Johannes Schindelin @ 2008-07-18 17:36 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200807182103.37272.angavrilov@gmail.com>
Hi,
On Fri, 18 Jul 2008, Alexander Gavrilov 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.)
> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> index 395c055..80c591a 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -481,6 +481,9 @@ in octal. Git only supports the following modes:
> what you want.
> * `100755` or `755`: A normal, but executable, file.
> * `120000`: A symlink, the content of the file will be the link target.
> +* `160000`: A gitlink, SHA-1 of the object refers to a commit in
> + another repository. Git links can only be specified by SHA or through
> + a commit mark. They are used to implements submodules.
s/\(implement\)s/\1/
> 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.
> @@ -183,7 +194,8 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)
> "", &rev->diffopt);
>
> 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?
> diff --git a/fast-import.c b/fast-import.c
> index e72b286..e7977c1 100644
> --- a/fast-import.c
> +++ b/fast-import.c
I'll let Shawn comment on that. Oh, wait, it's his last day in work
today. Maybe I have something useful to say about this part of the patch,
then, to save Shawn some work.
> @@ -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.
Oh, and your patch lacks test cases that demonstrate how you envisage the
whole thing to work.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Petr Baudis @ 2008-07-18 17:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <200807181905.07123.jnareb@gmail.com>
On Fri, Jul 18, 2008 at 07:05:05PM +0200, Jakub Narebski wrote:
> Dnia piątek 18. lipca 2008 18:48, Petr Baudis napisał:
> > On Tue, Jul 15, 2008 at 12:19:31AM +0200, Lea Wiemann wrote:
>
> > > No, you should never pass in an invalid SHA1 in the first place. The
> > > above piece of documentation is just a warning that bugs will show up
> > > delayed. IOW, this is not the right place to have your error handling.
> > >
> > > 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,
> > while all the Git commands can do the checks for you, if you give them
> > the chance.
> >
> > I was doing pretty much this thing in Cogito (initially out of
> > necessity) and it made it ungodly slow for any kind of batch operations.
>
> Lea probably would point out that thanks to '--batch-check' option
> to git-cat-file, and "reuse => 1" option to ->get_bidi_pipe you would
> need only one extra Git exec... BUT it is one extra Git exec per
> entire Perl script (one per request, for example, for gitweb).
> And it wouldn't help batching Perl script commands.
Even so, I don't like this restriction simply since it makes the usage
more complicated - in my commandline tool, I will be forced to write
my $csha1 = $repo->get_sha1($ARGV[0]);
$csha1 or die "a random inconsistent error message";
$repo->get_commit($csha1)
instead of
$repo->get_commit($ARGV[0]) # die if unresolved
and I don't understand why. Me and 80% of the scripts don't *care* about
some more graceful error handling, and if gitweb and the other 20%
(or less) do, *they* should do the extra work, not me.
--
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
* Re: copy selected history between repostories
From: Avery Pennarun @ 2008-07-18 17:12 UTC (permalink / raw)
To: luisgutz; +Cc: git
In-Reply-To: <18533605.post@talk.nabble.com>
On 7/18/08, luisgutz <luis@xmos.com> wrote:
> Is there any way to import that directory into repoA with all it's history,
> but NOT the history from the other commits?
> Another way of putting is this: can I make git forget the history of all
> other commits but those from this directory?
Try cloning the repository, then running git-filter-branch with the
--subdirectory-filter option. It works quite nicely.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Jakub Narebski @ 2008-07-18 17:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <20080718164828.GT10151@machine.or.cz>
Dnia piątek 18. lipca 2008 18:48, Petr Baudis napisał:
> On Tue, Jul 15, 2008 at 12:19:31AM +0200, Lea Wiemann wrote:
> > No, you should never pass in an invalid SHA1 in the first place. The
> > above piece of documentation is just a warning that bugs will show up
> > delayed. IOW, this is not the right place to have your error handling.
> >
> > 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,
> while all the Git commands can do the checks for you, if you give them
> the chance.
>
> I was doing pretty much this thing in Cogito (initially out of
> necessity) and it made it ungodly slow for any kind of batch operations.
Lea probably would point out that thanks to '--batch-check' option
to git-cat-file, and "reuse => 1" option to ->get_bidi_pipe you would
need only one extra Git exec... BUT it is one extra Git exec per
entire Perl script (one per request, for example, for gitweb).
And it wouldn't help batching Perl script commands.
--
Jakub Narebski
Poland
^ permalink raw reply
* [RFC PATCH] Support gitlinks in fast-import/export.
From: Alexander Gavrilov @ 2008-07-18 17:03 UTC (permalink / raw)
To: git
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>
---
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?
-- Alexander
Documentation/git-fast-import.txt | 3 +++
builtin-fast-export.c | 18 +++++++++++++++---
fast-import.c | 12 +++++++++++-
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 395c055..80c591a 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -481,6 +481,9 @@ in octal. Git only supports the following modes:
what you want.
* `100755` or `755`: A normal, but executable, file.
* `120000`: A symlink, the content of the file will be the link target.
+* `160000`: A gitlink, SHA-1 of the object refers to a commit in
+ another repository. Git links can only be specified by SHA or through
+ a commit mark. They are used to implements submodules.
In both formats `<path>` is the complete path of the file to be added
(if not already existing) or modified (if already existing).
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;
+
+ if (mark)
+ printf("M %06o :%d %s\n", spec->mode,
+ mark, spec->path);
+ else {
+ if (!S_ISGITLINK(spec->mode))
+ die("Unknown object added: %s at %s",
+ sha1_to_hex(spec->sha1), spec->path);
+
+ printf("M %06o %s %s\n", spec->mode,
+ sha1_to_hex(spec->sha1), spec->path);
+ }
}
}
}
@@ -183,7 +194,8 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)
"", &rev->diffopt);
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);
mark_object(&commit->object);
if (!is_encoding_utf8(encoding))
diff --git a/fast-import.c b/fast-import.c
index e72b286..e7977c1 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1868,6 +1868,7 @@ static void file_change_m(struct branch *b)
case S_IFREG | 0644:
case S_IFREG | 0755:
case S_IFLNK:
+ case S_IFGITLINK:
case 0644:
case 0755:
/* ok */
@@ -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);
+ }
+ } else if (inline_data) {
static struct strbuf buf = STRBUF_INIT;
if (p != uq.buf) {
--
1.5.6.3.18.gfe82
^ permalink raw reply related
* [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 17:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Jon Smirl
In-Reply-To: <20080718084127.GA7042@diana.vm.bytemark.co.uk>
We currently can't -- this is bug 12038, found by Jon Smirl. See
https://gna.org/bugs/index.php?12038
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Here's a proper test that demonstrates the bug. It applies to the
stable branch.
t/t2701-refresh-p.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100755 t/t2701-refresh-p.sh
diff --git a/t/t2701-refresh-p.sh b/t/t2701-refresh-p.sh
new file mode 100755
index 0000000..d42e90f
--- /dev/null
+++ b/t/t2701-refresh-p.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='Run "stg refresh -p"'
+
+. ./test-lib.sh
+
+# Ignore our own temp files.
+cat >> .git/info/exclude <<EOF
+expected*.txt
+files*.txt
+status*.txt
+EOF
+
+test_expect_success 'Initialize StGit stack' '
+ stg init &&
+ for i in 1 2; do
+ echo x > $i.txt &&
+ git add $i.txt &&
+ stg new p$i -m "Patch $i" &&
+ stg refresh
+ done
+'
+
+touch expected0.txt
+cat > expected1.txt <<EOF
+A 1.txt
+A new.txt
+EOF
+cat > expected2.txt <<EOF
+A 2.txt
+EOF
+test_expect_failure 'Add new file to non-top patch' '
+ stg status > status1.txt &&
+ diff -u expected0.txt status1.txt &&
+ echo y > new.txt &&
+ git add new.txt &&
+ stg refresh -p p1 &&
+ stg status > status2.txt &&
+ diff -u expected0.txt status2.txt &&
+ stg files p1 > files1.txt &&
+ diff -u expected1.txt files1.txt &&
+ stg files p2 > files2.txt &&
+ diff -u expected2.txt files2.txt
+'
+
+test_done
^ permalink raw reply related
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