On Fri, Sep 07, 2007 at 12:14:30AM +0200, Lars Hjemli wrote:
> On 9/6/07, Eric Wong <normalperson@xxxxxxxx> wrote:
> > Wait, actually. --upstream won't ever populate the refs array in
> > working_head_info for dcommit
>
> Sorry, I didn't realize that working_head_info() collected commit-ids
> later used by dcommit. But to implement --upstream we could maybe do
> something like this:
>
> sub working_head_info {
> my ($head, $refs) = @_;
>
> if (defined $_upstream) {
> working_head_info_traverse($head, \$refs);
> return working_head_info_traverse($_upstream, undef);
> }
>
> return working_head_info_traverse($head, \$refs);
> }
>
> sub working_head_info_traverse {
> my ($head, $refs) = @_;
> my ($fh, $ctx) = command_output_pipe('log', '--no-color',
> '--first-parent', $head);
> ...
>
>
> (This was written straight into firefox, late at night, by a perl
> illiterate. Please be gentle...)
>
Sorry, but isn't --upstream just the wrong way to do what you want?
Why should I specify a GIT commit to leat git-svn figure out on what
upstream SVN branch I want to commit? To me, this seems a little
backwards. Wouldn't it be much more pleasant to say something like
git-svn dcommit --on the_branch
whereas 'the_branch' is the name of the upstream branch as specified
in the fetch/branch section in the git config? If I do a dcommit I know
*exactly* on which svn branch it should go, so why can't I specify it on
the cmdline? ... or did I miss something obvious?
-Peter
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
