* 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
* 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 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
* 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: [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: 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: 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: [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: [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: [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] 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] Windows: set gitexecdir = $(bindir)
From: Junio C Hamano @ 2008-07-19 0:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1216366485-12201-5-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> The "dash-less" change aims to remove git commands from $PATH. It does so
> by defining a GIT_EXEC_PATH that is different from $(bindir). On Windows
> we want a relocatable installation of the git tool, so we cannot use an
> absolute GIT_EXEC_PATH. Therefore, the implementation of
> builtin_exec_path() on Windows derives the exec-path from the command
> invocation,...
Sorry, I am not sure if I understand what you are trying to solve. If you
have ../libexec/git-core/ in GIT_EXEC_PATH (or have builtin_exec_path()
use it), then your installation would look like this:
[[some random place]]
bin/git
libexec/git-core/git-add
libexec/git-core/git-del
libexec/git-core/git-dir
...
and if "git" can figure out it is "[[some random place]]/bin/git",
it can find its subcommands from neighbouring directory, that is still
inside the random place the user told the installer to use, can't it?
> This counteracts the aims of the "dash-less" change on Windows, but better
> this way than having no working git at all.
I'd agree to the extent that anything is better than having no working
git, but this somewhat feels backwards.
^ permalink raw reply
* Re: copy selected history between repostories
From: Nick Andrew @ 2008-07-19 1:01 UTC (permalink / raw)
To: luisgutz; +Cc: git
In-Reply-To: <18533605.post@talk.nabble.com>
On Fri, Jul 18, 2008 at 09:58:49AM -0700, luisgutz 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?
I couldn't figure out git-filter-branch, so I did the following,
which worked for me:
First, export commits as patches in mbox format:
git log -p --first-parent --reverse --pretty=email $* > mbox
Second, run the mbox file through a filter which selectively
renames files (since almost always I want the files in a different
directory in the new repository):
myfilter scripts=bin perllib=lib < mbox > mbox2
Finally, import into new repo:
git-am mbox2
It's a bit slow on the import step but it meets my needs at this time.
Nick.
Filter script follows, for what it's worth ...
#!/usr/bin/perl
# @(#) git-filter-rename.pl
#
# Read an mbox file containing patches on standard input,
# modify the filenames within according to a list of substitutions
# supplied on the command line, and write the modified mbox file
# to standard output.
my @subs;
foreach (@ARGV) {
if (/(.*)=(.*)/) {
my $len = length($1);
push(@subs, [ $1, $2, $len ]);
} else {
print STDERR "Unknown arg: $_\n";
}
}
while (<STDIN>) {
chomp;
my $line = $_;
if ($line =~ /^(---|\+\+\+) ([ab]\/)(.+)$/) {
my $line_1 = $1;
my $line_2 = $2;
my $line_3 = $3;
subFilename($line_3);
print "$line_1 $line_2$line_3\n";
next;
}
if ($line =~ /^diff --git ([ab]\/)(\S+) ([ab]\/)(\S+)/) {
my ($line_1, $line_2, $line_3, $line_4) = ($1, $2, $3, $4);
subFilename($line_2);
subFilename($line_4);
print "diff --git $line_1$line_2 $line_3$line_4\n";
next;
}
print $line, "\n";
}
exit(0);
# ------------------------------------------------------------------------
# Substitute a filename in-place (modifies argument)
# ------------------------------------------------------------------------
sub subFilename {
foreach my $lr (@subs) {
my ($lhs, $rhs, $len) = @$lr;
if (substr($_[0], 0, $len) eq $lhs) {
print STDERR "Match on $lhs, $_[0]\n";
substr($_[0], 0, $len) = $rhs;
last;
}
}
}
^ permalink raw reply
* Re: copy selected history between repostories
From: Johannes Schindelin @ 2008-07-19 1:12 UTC (permalink / raw)
To: Nick Andrew; +Cc: luisgutz, git
In-Reply-To: <20080719010122.GA12047@mail.local.tull.net>
Hi,
On Sat, 19 Jul 2008, Nick Andrew wrote:
> myfilter scripts=bin perllib=lib < mbox > mbox2
Note that if your repository only contains text files, "git fast-export |
my-filter | git fast-import --force" would have worked faster, probably.
But I am glad you figured out how to do what you wanted to do.
Ciao,
Dscho
^ permalink raw reply
* Re: Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]
From: Johannes Schindelin @ 2008-07-19 1:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48806D03.30603@fastmail.fm>
Hi,
On Fri, 18 Jul 2008, 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?
>
> 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".
Actually, I do not particularly like that direction.
Recently, somebody taught me that it makes sense, from the psychological
view, to stress positive points, and avoid negative terms.
For example, "do not use this" -- even if followed by "use that instead"
-- is suboptimal. People will be more stressed, have a shorter attention
span, and in general recall much less, if you use negative terms.
So what I really would like is this: leave the plumbing pages as they are,
but enhance those pages that users (especially new ones) are likely to see
most often.
By "enhancing" I mean to illustrate the principles and commands more in
term of a select _few_ commands. And they should describe the options
themselves, instead of referring to plumbing man pages.
Maybe I'll find some time this weekend to write up a bit more of my
tutorials, which I would then post so people see what I mean should be
taught to n00bs first.
Ciao,
Dscho
^ permalink raw reply
* Re: copy selected history between repostories
From: Jeff King @ 2008-07-19 1:21 UTC (permalink / raw)
To: Nick Andrew; +Cc: luisgutz, git
In-Reply-To: <20080719010122.GA12047@mail.local.tull.net>
On Sat, Jul 19, 2008 at 11:01:22AM +1000, Nick Andrew wrote:
> I couldn't figure out git-filter-branch, so I did the following,
> which worked for me:
>
> First, export commits as patches in mbox format:
>
> git log -p --first-parent --reverse --pretty=email $* > mbox
> [...]
>
> Finally, import into new repo:
>
> git-am mbox2
Note that this will lose any interesting history topology you had, like
branching and merging (and it may have trouble applying all patches in
that case, too). But if your history was a straight line, it should
produce equivalent results.
-Peff
^ permalink raw reply
* Re: [RFC PATCH] Support gitlinks in fast-import/export.
From: Johannes Schindelin @ 2008-07-19 1:22 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Alexander Gavrilov, git
In-Reply-To: <20080718204338.GB27528@spearce.org>
Hi,
On Fri, 18 Jul 2008, Shawn O. Pearce wrote:
> Alexander Gavrilov <angavrilov@gmail.com> wrote:
>
> > 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.
Oh, I just realized that fast-import expects changes, instead of full
snapshots.
So strike all my suggestions regarding gitlink marks.
Sorry,
Dscho
^ permalink raw reply
* Re: gitdm v0.10 available
From: Petr Baudis @ 2008-07-19 1:59 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: LKML, git, Greg KH
In-Reply-To: <20080718154657.7ff0cf9e@bike.lwn.net>
Hi,
On Fri, Jul 18, 2008 at 03:46:57PM -0600, Jonathan Corbet wrote:
> 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.
or you can examine it over gitweb now set up at
http://repo.or.cz/w/git-dm.git
Petr "Pasky" Baudis
^ permalink raw reply
* I've visited your website http://git.or.cz/
From: info @ 2008-07-19 2:15 UTC (permalink / raw)
To: git
Hi,
We've seen your website at http://git.or.cz/
and we love it!
We see that your traffic rank is 77673
and your link popularity is 128.
Also, you have been online since <Online since>.
With that kind of traffic, we will pay you up to $4,800/month
to advertise our links on your website.
If you're interested, read our terms from this page:
http://www.contactthem.ws/hit.php?s=10&p=2&w=117652
Sincerely,
Scot Ricker
The ContactThem Network
505-984-0229 mountain time
email: info@scotricker.ws
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nanako Shiraishi @ 2008-07-19 5:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vtzen7bul.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> I tried not to sound too negative when describing -Xours and -Xtheirs
> there, but actually I think "-s theirs" is even worse. It is how you
> would discard what you did (perhaps because the other side has much better
> solution than your hack), but that can be much more easily and cleanly
> done with:
>
> $ git reset --hard origin
>
> Some poeple might say "But with 'merge -s theirs', I can keep what I did,
> too". That reset is simply discarding what I did.
>
> That logic also is flawed. You can instead:
>
> $ git branch i-was-stupid
> $ git reset --hard origin
>
> if you really want to keep record of your failure.
>
> One big problem "-s theirs" has, compared to the above "reset to origin,
> discarding or setting aside the failed history" is that your 'master'
> history that your further development is based on will keep your failed
> crap in it forever if you did "-s theirs". Hopefully you will become a
> better programmer over time, and you may eventually have something worth
> sharing with the world near the tip of your master branch. When that
> happens, however, you _cannot_ offer your master branch to be pulled by
> the upstream, as the wider world will not be interested in your earlier
> mistakes at all.
Thanks for sharing your insight. Perhaps the above can become a separate pargraph to explains why there is no "theirs" merge strategy somewhere in the manual?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-19 5:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807181351370.3932@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 18 Jul 2008, Junio C Hamano wrote:
>
>> +The 'recursive' strategy can take the following options:
>> +
>> +ours;;
>
> You still have not addressed the issue that you can specify multiple
> strategies,...
Even though multiple -s parameters are supported, I know you have been
here long enough in git scene to remember how it came about. I've seen
some third-party documents that talk about our ability to "try multiple
strategies and pick the best one" as one of the unique features, but
anybody who was there knows that it was just a failed experiment that we
did not bother removing.
The thing is, trying multiple strategies was a cute idea and it was quite
straightforward to implement. But picking the best one is the much more
important part, and judging whose result is the best shouldn't be done
with just a naïve "how many conflicting paths remain there?" metric
(c.f. $gmane/87297 which talks about "stupid" but the argument is exactly
the same --- smaller number of conflicts may not necessarily be the
easiest to resolve nor the right resolution). I would be surprised if
anybody uses multiple -s options in their daily workflow, even though I
would not be surprised if people tried to use it just as an experiment and
for its entertainment value once or maybe twice. After all, I invented
the multiple strategy support for amusement, not from any practical real
world needs ;-)
So I do not consider that a convincing argument at all.
> ... or even a single _wrong_ one. So:
>
> $ git merge -s stupid -Xours
>
> would not fail at all, but definitely not do the right thing either (it
> disobeys a direct command of the user).
It does fail gracefully, though.
$ git merge -s resolve -Xours next
Trying really trivial in-index merge...
error: Untracked working tree file '.gitattributes' would be overwritten by merge.
Nope.
fatal: Not a valid object name --ours
Merge with strategy resolve failed.
I consider this falls into "You say it hurts? Don't do that, then"
category.
The error message will naturally improve, once we teach the merge strategy
backends that they can be given --<option> in front of the usual
<base>... -- <ents>... parameters, and there is no risk of ambiguity
because no object names begin with a dash.
Having said all that, I do not have any reason to push for -Xours/theirs
myself. I've made myself very clear from the beginning that what these
options do is a bad idea, just as "-s theirs" is a bad idea. These
encourage a broken workflow and I do not see a clear upside, however
narrow, and you and Pasky seem to agree with me (heh, isn't it a rare
occasion that all three of us agree on something these days? ;-)
I won't shed tears to see them go.
However, I do think it is wrong to deny that it will eventually be
necessary for us to be able to pass strategy specific options via the
git-merge frontend driver to the strategy backend. The primary reason why
I wrote "subtree" strategy to _guess_ how to shift trees was because there
was no way to pass "how the end user wants to shift them" to the strategy
backend over "pull -- merge -- merge-subtree" callchain. Coming up with
the algorithm was fun, but that was secondary.
If we allow users to say -Xsubtree=<path>, it would be a true improvement
to a tool that is used in real life. Unlike "multiple -s strategy"
support that I think nobody ever uses in practice (on which part of your
objection is based), "-s subtree" has been useful in real life, and you
can verify that claim easily by counting how many times I've used that in
git.git history yourself.
Even though I do not care deeply about the syntax (and if you do not like
the "-X" as the external option introducer, you are welcome to pick a
different notation and send in a patch), it would help for example the
vanilla "recursive" strategy to allow the user, when dealing with really
tricky merge, to influence the rename threshold score it uses by passing
it as a strategy-specific option.
As a conclusion of this discussion, I'll discard xx/merge-in-c-into-next
branch from "next", at the beginning of post-1.6.0 cycle. We might in the
future need to resurrect only the -X<option> part to allow us to pass
strategy specific options (that are not "ours/theirs"), but there is no
immediate need for it, other than -Xsubtree=<path>. If somebody wants to
step up and give the custom rename threshold to the recursive strategy,
keeping that code to do -X<option> might help that too, though.
^ permalink raw reply
* Re: [PATCH 0/3] Git::Repo API and gitweb caching
From: Lea Wiemann @ 2008-07-19 5:35 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Git Mailing List, John Hawley, Jakub Narebski, Petr Baudis
In-Reply-To: <4876B223.4070707@gmail.com>
Lea Wiemann wrote:
> 1) adding the Mechanize tests,
> 2) adding the Git::Repo API, and (the important part:)
> 3) making gitweb use the Git::Repo API, and adding caching to gitweb.
I unfortunately didn't have enough time to finish the update to the
patch series before my vacation; I'll therefore be posting the next
series only around Aug 12th-13th. I suggest you wait with any reviewing
till I've posted the next version, since there'll be quite a few
changes; also I'll post patch 3 (the gitweb patch) as (at least) two
separate patches, which will hopefully help with reviewability.
Alright, off to my vacation now -- I'll be completely offline till Aug 10th.
See you then!
-- Lea
^ permalink raw reply
* PATCH: git-svn -- apply autoprop properties to an upstream svn repository
From: Paul Talacko @ 2008-07-19 7:22 UTC (permalink / raw)
To: git
Hello,
As suggested a few days ago, there has been some interest git-svn being able to set properties on upstream svn repositories This is, for example, necessary for committing new files to subversion repositories hosted on sourceforge where svn:mime-type and svn:eol-style properties have to be set for a commit to succeed.
So, here's a patch that reads the standard subversion config file and applies the "auto-props" to new files being committed to the upstream repository. This file is normally in ~/.subversion/config or /etc/subversion/config but this can be overridden with the --config-dir option.
In this patch, I've decided that to keep it consistent with the svn command line tool, that is that git-svn should read the config file by default, but respect the enable-auto-props config option set in that config file.
Also, to keep it consistent with the svn command line tool, the patch includes two new command line options --auto-props and --no-auto-props which both override the enable-auto-props config file option.
The code borrows from SVK::XD, in particular the regexp. All the SVK code is released under the GPL.
I have also included a test file.
diff --git a/git-svn.perl b/git-svn.perl
index a366c89..df06220 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -128,6 +128,8 @@ my %cmd = (
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
'no-rebase' => \$_no_rebase,
+ 'auto-props' => \$SVN::Git::Editor::_auto_props,
+ 'no-auto-props' => \$SVN::Git::Editor::_no_auto_props,
%cmt_opts, %fc_opts } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
@@ -448,8 +450,8 @@ sub cmd_dcommit {
log => get_commit_entry($d)->{log},
ra => Git::SVN::Ra->new($gs->full_url),
config => SVN::Core::config_get_config(
- $Git::SVN::Ra::config_dir
- ),
+ $Git::SVN::Ra::config_dir
+ ),
tree_a => "$d~1",
tree_b => $d,
editor_cb => sub {
@@ -3276,7 +3278,7 @@ sub close_edit {
}
package SVN::Git::Editor;
-use vars qw/@ISA $_rmdir $_cp_similarity $_find_copies_harder $_rename_limit/;
+use vars qw/@ISA $_rmdir $_cp_similarity $_find_copies_harder $_rename_limit $_auto_props $_no_auto_props/;
use strict;
use warnings;
use Carp qw/croak/;
@@ -3309,6 +3311,8 @@ sub new {
$self->{rm} = { };
$self->{path_prefix} = length $self->{svn_path} ?
"$self->{svn_path}/" : '';
+ $self->{config} = $opts->{ra}->{config};
+ croak "--auto-props and --no-auto-props are mutually exclusive." if $_auto_props && $_no_auto_props;
return $self;
}
@@ -3497,6 +3501,86 @@ sub ensure_path {
return $bat->{$c};
}
+sub apply_properties {
+ my ( $self, $fbat, $m ) = @_;
+ my $config = $self->{config}->{config};
+ my $svn_auto_prop = {};
+ return if $_no_auto_props;
+ return if ( ! $_auto_props ) && ( ! $config->get_bool ('miscellany', 'enable-auto-props', 0) );
+
+ my $file = $m->{ file_b };
+
+ $config->enumerate(
+ 'auto-props',
+ sub {
+ $svn_auto_prop->{ compile_apr_fnmatch( $_[0] ) } = $_[1];
+ 1;
+ }
+ );
+ my ( $filebase ) = File::Basename::fileparse( $file );
+ while (my ($pattern, $value) = each %$svn_auto_prop ) {
+ next unless $filebase =~ m/$pattern/;
+ for (split (/\s*;\s*/, $value)) {
+ my ($propname, $propvalue) = split (/\s*=\s*/, $_, 2);
+ $self->change_file_prop($fbat, $propname, $propvalue);
+ }
+ }
+
+}
+
+
+## Thanks to SVK::XD and the folks Best Practical Solutions, who in
+## turn based this on Barrie Slaymaker's Regexp::Shellish
+sub compile_apr_fnmatch {
+ my $re = shift;
+
+ $re =~ s@
+ ( \\.
+ | \[ # character class
+ [!^]? # maybe negation (^ and ! are both supported)
+ (?: (?:\\.|[^\\\]]) # one item
+ (?: - # possibly followed by a dash and another
+ (?:\\.|[^\\\]]))? # item
+ )* # 0 or more entries (zero case will be checked specially below)
+ (\]?) # if this ] doesn't match, that means we fell off end of string!
+ | .
+ )
+ @
+ if ( $1 eq '?' ) {
+ '.' ;
+ } elsif ( $1 eq '*' ) {
+ '.*' ;
+ } elsif ( substr($1, 0, 1) eq '[') {
+ if ($1 eq '[]') { # should never match
+ '[^\s\S]';
+ } elsif ($1 eq '[!]' or $1 eq '[^]') { # 0-length match
+ '';
+ } else {
+ my $temp = $1;
+ my $failed = $2 eq '';
+ if ($failed) {
+ '[^\s\S]';
+ } else {
+ $temp =~ s/(\\.|.)/$1 eq '-' ? '-' : quotemeta(substr($1, -1))/ges;
+ # the previous step puts in backslashes at beginning and end; remove them
+ $temp =~ s/^\\\[/[/;
+ $temp =~ s/\\\]$/]/;
+ # if it started with [^ or [!, it now starts with [\^ or [\!; fix.
+ $temp =~ s/^\[ # literal [
+ \\ # literal backslash
+ [!^] # literal ! or ^
+ /[^/x;
+ $temp;
+ }
+ }
+ } else {
+ quotemeta(substr( $1, -1 ) ); # ie, either quote it, or if it's \x, quote x
+ }
+ @gexs ;
+
+ return qr/\A$re\Z/s;
+}
+
sub A {
my ($self, $m) = @_;
my ($dir, $file) = split_path($m->{file_b});
@@ -3505,6 +3589,7 @@ sub A {
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
$self->chg_file($fbat, $m);
+ $self->apply_properties( $fbat, $m );
$self->close_file($fbat,undef,$self->{pool});
}
diff --git a/t/t9124-git-svn-autoprops.sh b/t/t9124-git-svn-autoprops.sh
new file mode 100644
index 0000000..ed78c2d
--- /dev/null
+++ b/t/t9124-git-svn-autoprops.sh
@@ -0,0 +1,123 @@
+#!/bin/sh
+#
+
+
+
+test_description='git-svn dcommit sets autoprops on files'
+
+. ./lib-git-svn.sh
+
+test_expect_success 'make svn repo' '
+ mkdir import &&
+ cd import &&
+ echo first > firstfile &&
+ svn import -m "Import for autoprops test" . "$svnrepo" > /dev/null &&
+ cd .. &&
+ git svn init "$svnrepo" &&
+ git svn fetch
+'
+
+
+mkdir config
+cat > config/config <<EOF
+[miscellany]
+enable-auto-props = yes
+[auto-props]
+*pm = file-type = perl
+*html = svn:mime-type = text/html; encoding = special
+*bar = private = thingy
+EOF
+
+
+
+test_expect_success 'set svn properties on files' '
+ cd "$gittestrepo" &&
+ echo "blah" > a.pm &&
+ echo "foo" > b.html &&
+ echo "data" > foobar &&
+ git add a.pm b.html foobar &&
+ git commit -m files &&
+ git svn dcommit --config-dir=config
+ '
+
+test_expect_success 'export our properties to an svn repo' '
+
+ mkdir testsvnrepo &&
+ cd testsvnrepo &&
+ svn checkout "$svnrepo" &&
+ cd svnrepo
+ '
+
+test_expect_success 'test properties' '
+ test perl = `svn propget file-type a.pm` &&
+ test thingy = `svn propget private foobar` &&
+ test text/html = `svn propget svn:mime-type b.html` &&
+ test special = `svn propget encoding b.html`
+
+ '
+
+cd ../..
+
+test_expect_success 'no-props overrides config file' '
+ touch overriden-b.html &&
+ git add overriden-b.html &&
+ git commit -m "overriden-b" &&
+ git svn dcommit --no-auto-props --config-dir=config &&
+ cd testsvnrepo &&
+ svn checkout "$svnrepo" &&
+ cd svnrepo &&
+ test -z `svn propget file-type overriden-b.html`
+'
+
+cd ../..
+
+cat > config/config <<EOF
+[miscellany]
+enable-auto-props = no
+[auto-props]
+*pm = file-type = perl
+*html = svn:mime-type = text/html; encoding = special
+*bar = private = thingy
+EOF
+
+
+test_expect_success 'test when enable-auto-props is no' '
+ echo "blah" > a_no_props.pm &&
+ echo "foo" > b_no_props.html &&
+ echo "data" > foobar_no_props &&
+ chmod +x foobar_no_props &&
+ git add a_no_props.pm b_no_props.html foobar_no_props &&
+ git commit -m "No props files" &&
+ git svn dcommit --config-dir=config &&
+ cd testsvnrepo &&
+ svn checkout "$svnrepo" &&
+ cd svnrepo &&
+ test -z `svn propget file-type a_no_props.pm` &&
+ test -z `svn propget private foobar_no_props` &&
+ test -z `svn propget svn:mime-type b_no_props.html` &&
+ test -z `svn propget encoding b_no_props.html`
+ '
+
+cd ../..
+
+test_expect_success 'auto-props overrides config file' '
+ touch overriden-auto.pm &&
+ git add overriden-auto.pm &&
+ git commit -m "overriden-auto" &&
+ git svn dcommit --auto-props --config-dir=config &&
+ cd testsvnrepo &&
+ svn checkout "$svnrepo" &&
+ cd svnrepo &&
+ test perl = `svn propget file-type overriden-auto.pm`
+'
+cd ../..
+
+test_expect_success 'auto-props and no-auto-props are exclusive' '
+ touch afile &&
+ git add afile &&
+ git commit -m afile &&
+ test_must_fail git svn dcommit --auto-props --no-auto-props
+'
+
+test_done
+
__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
^ permalink raw reply related
* Out-of-repository file remove error
From: Nick Andrew @ 2008-07-19 8:23 UTC (permalink / raw)
To: git
git rm seems to have a problem with removing a file from a repository
when the repository .git and working tree are not in the current
directory. It leaves an index.lock file.
Here's a script to show the bug:
mkdir Bugtest
cd Bugtest
git init
date > newfile
git add newfile
git commit -m 'Added' newfile
cd ..
git --git-dir=Bugtest/.git --work-tree=Bugtest rm newfile
ls -l Bugtest/.git/index.lock
Output:
Initialized empty Git repository in .../Bugtest/.git/
Created initial commit 43dec15: Added
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 newfile
rm 'newfile'
fatal: Unable to write new index file
-rw-r--r-- 1 nick nick 32 Jul 19 18:20 Bugtest/.git/index.lock
I tested on:
git version 1.5.6.2
git version 1.5.6.3.440.g9d8f
Nick.
^ permalink raw reply
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Johannes Sixt @ 2008-07-19 8:52 UTC (permalink / raw)
To: Junio C Hamano, Steffen Prohaska; +Cc: git, Johannes Schindelin
In-Reply-To: <7vej5q67dq.fsf@gitster.siamese.dyndns.org>
On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> Sorry, I am not sure if I understand what you are trying to solve. If you
> have ../libexec/git-core/ in GIT_EXEC_PATH (or have builtin_exec_path()
> use it), then your installation would look like this:
>
> [[some random place]]
> bin/git
> libexec/git-core/git-add
> libexec/git-core/git-del
> libexec/git-core/git-dir
> ...
>
> and if "git" can figure out it is "[[some random place]]/bin/git",
> it can find its subcommands from neighbouring directory, that is still
> inside the random place the user told the installer to use, can't it?
Yes, but...
Take as an example 'git pull'.
- The first call to git will derive the exec-path
$prefix/bin/../libexec/git-core and prepend it to $PATH.
- Calls to builtin git commands from inside 'git pull' will then derive the
exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is
$prefix/libexec/libexec/git-core, and prepend it to $PATH as well. That
directory does not exist - usually - and it does not hurt. But it feels dirty
and potentially dangerous.
> > This counteracts the aims of the "dash-less" change on Windows, but
> > better this way than having no working git at all.
>
> I'd agree to the extent that anything is better than having no working
> git, but this somewhat feels backwards.
It certainly does.
I'm hoping that the msysgit crew has an opinion on this. CMD users like me do
not care how cluttered $PATH is because there is no command completion that
would reveal the 100+ git commands. But msysgit users who are working from a
bash may want to have them hidden outside $PATH. Or maybe they do not care.
-- Hannes
^ 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