* Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Junio C Hamano @ 2006-12-13 22:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Johannes Schindelin, git
In-Reply-To: <b0943d9e0612131401s6cde6d0du5e3c6d2e34bfbbb2@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 13/12/06, Junio C Hamano <junkio@cox.net> wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
> What is this new xdl_merge()? Is it a better replacement for diff3? In
> this situation diff3 would actually show two confict parts, each of
> them being the full file, with an empty ancestor.
The calls to xdl_merge() from merge-recursive replace
invocations to external "merge" from RCS suite.
An older merge-recursive had a bug (as you noticed and adjusted
StGIT with the commit 8d41555) in that it did not leave anything
in the working tree in add/add situation, while merge-resolve
would have left its best attempt of ancestor-less two file merge
(which is not necessarily the straight diff3 "no common section,
full copies from both" result). The change in question corrects
that problem and merge-recursive would create a file in the
working tree just like merge-resolve would.
You were CC'ed just in case this change in behaviour might
interact with the abovementioned change in StGIT, but as you say
the change would not break StGIT, we would all be happy ;-).
^ permalink raw reply
* [PATCH] repacked packs should be read-only
From: Nicolas Pitre @ 2006-12-13 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
... just like the other pack creating tools do.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/git-repack.sh b/git-repack.sh
index f150a55..067898f 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -67,6 +67,8 @@ name=$(git-pack-objects --non-empty --all $args </dev/null "$PACKTMP") ||
if [ -z "$name" ]; then
echo Nothing new to pack.
else
+ chmod a-w "$PACKTMP-$name.pack"
+ chmod a-w "$PACKTMP-$name.idx"
if test "$quiet" != '-q'; then
echo "Pack pack-$name created."
^ permalink raw reply related
* Re: svn versus git
From: J. Bruce Fields @ 2006-12-13 22:18 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612132200.41420.andyparkins@gmail.com>
On Wed, Dec 13, 2006 at 10:00:37PM +0000, Andy Parkins wrote:
> svn add::
> Put files and directories under version control, scheduling them for
> addition to repository. They will be added in next commit. This
> doesn't really add anything, it just schedules.
> git add::
> Add files to the index file. This command does not simply schedule. It
> takes the current contents of the file and copies it to the git staging
> area.
>
> The git index makes this command more complicated for git; however git
> is using the verb "add" more correctly. In the subversion case, nothing
> is actually added to a repository, it is merely scheduled for addition.
Well, you could argue whether adding something to the index is really
adding it to "a repository".
> svn cat::
> Output the contents of specified files or URLs. Optionally at a
> specific revision.
> git cat-file -p $(git-ls-tree $REV $file | cut -d " " -f 3 | cut -f 1)::
> git-ls-tree lists the object ID for $file in revision $REV, this is cut
> out of the output and used as an argument to git-cat-file, which should
> really be called git-cat-object, and simply dumps that object to stdout.
>
> Subversion wins. This is a distinctly non-user friendly way of reading
> a file.
Still, unfriendly, but not quite as bad:
git -p cat-file -p revision:path
> svn diff::
> Display the differences between two paths. Defaults to showing the
> differences between HEAD and the working copy.
> git diff::
> As for svn;
though note slightly different default. (Diffs against index, not
HEAD).
^ permalink raw reply
* Re: [PATCH] Allow subcommand.color and color.subcommand color configuration
From: Junio C Hamano @ 2006-12-13 22:16 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Eric Wong
In-Reply-To: <200612130913.28917.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> While adding colour to the branch command it was pointed out that a
> config option like "branch.color" conflicts with the pre-existing
> "branch.something" namespace used for specifying default merge urls and
> branches. The suggested solution was to flip the order of the
> components to "color.branch", which I did for colourising branch.
> ...
> Unfortunately git-svn reads "diff.color" and "pager.color"; which I
> don't like to change unilaterally.
I think doing the same makes sense. Something like this?
-- >8 --
git-svn: allow both diff.color and color.diff
The list concensus is to group color related configuration under
"color.*" so let's be consistent.
Inspired by Andy Parkins's patch to do the same for diff/log
family.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-svn.perl b/git-svn.perl
index ec92b44..2893e3b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -925,19 +925,38 @@ sub cmt_showable {
sub log_use_color {
return 1 if $_color;
- my $dc;
- chomp($dc = `git-repo-config --get diff.color`);
+ my ($dc, $dcvar);
+ $dcvar = 'color.diff'
+ $dc = `git-repo-config --get $dcvar`;
+ if ($dc eq '') {
+ # nothing at all; fallback to "diff.color"
+ $dcvar = 'diff.color';
+ $dc = `git-repo-config --get $dcvar`;
+ }
+ chomp($dc);
if ($dc eq 'auto') {
- if (-t *STDOUT || (defined $_pager &&
- `git-repo-config --bool --get pager.color` !~ /^false/)) {
+ my $pc;
+ $pc = `git-repo-config --get color.pager`;
+ if ($pc eq '') {
+ # does not have it -- fallback to pager.color
+ $pc = `git-repo-config --bool --get pager.color`;
+ }
+ else {
+ $pc = `git-repo-config --bool --get color.pager`;
+ if ($?) {
+ $pc = 'false';
+ }
+ }
+ chomp($pc);
+ if (-t *STDOUT || (defined $_pager && $pc eq 'true') {
return ($ENV{TERM} && $ENV{TERM} ne 'dumb');
}
return 0;
}
return 0 if $dc eq 'never';
return 1 if $dc eq 'always';
- chomp($dc = `git-repo-config --bool --get diff.color`);
- $dc eq 'true';
+ chomp($dc = `git-repo-config --bool --get $dcvar`);
+ return ($dc eq 'true');
}
sub git_svn_log_cmd {
^ permalink raw reply related
* Re: Collection of stgit issues and wishes
From: Catalin Marinas @ 2006-12-13 22:14 UTC (permalink / raw)
To: Yann Dirson; +Cc: Jakub Narebski, git
In-Reply-To: <20061211184105.GC17132@nan92-1-81-57-214-146.fbx.proxad.net>
On 11/12/06, Yann Dirson <ydirson@altern.org> wrote:
> Operations just shuffling the stack (eg. "float -s", or "push XXX;
> push --undo") would probably require putting the series file itself
> under version-control.
It depends on the numver of undos allowed. With only one, you could
have a series.old file or similar.
I'll try to add a wiki page with todo/wishlist ideas and prioritise
those included before 1.0. Post 1.0, I'll try to look at changing the
repository layout a bit to reduce the amount of metadata and also
facilitate the support for transactions etc.
--
^ permalink raw reply
* Re: StGit repo & gitweb, was Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Catalin Marinas @ 2006-12-13 22:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <Pine.LNX.4.63.0612131232270.3635@wbgn013.biozentrum.uni-wuerzburg.de>
On 13/12/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 12 Dec 2006, Junio C Hamano wrote:
>
> > Although I would feel very happy about this change, Catalin
> > might want to be informed about potential interaction this
> > change might have with his commit 8d41555 in StGIT.
>
> Indeed. Catalin, do you have any suggestion how to proceed? Do you want to
> introduce a check if the file exists prior to re-generating it? Or do you
> need some version check?
It currently checks whether the file exists and, if it doesn't, it is
re-generated. I think the patch is good idea.
> BTW why is StGit not on kernel.org?
Why would it be? Unless you know who to talk to for this :-), it's not
really a derivative of the Linux kernel.
> Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
> that machine? I am a happy user of the gitweb interface on that box...
Hopefully, when I get a bit of time, I'll try to give up the
http-hosted repository and use Pasky's one exclusively.
BTW, how can I notify people that only pull from the http repository
that it will no longer be updated (rather than them thinking the
development stopped)? One solution would be to create a file with a
meaningful name in the top dir and hope people will notice it.
--
^ permalink raw reply
* svn versus git
From: Andy Parkins @ 2006-12-13 22:00 UTC (permalink / raw)
To: git
Hello,
With all the discussion about user interface difficulties, I started to write
a comparison with subversion document. (I was assuming that people find
subversion easy). As much as I love git, I was expecting to find that it's
hard to use interface would have subversion as the clear winner. I was
hoping that would then give guidance as to what could be fixed in git.
I was surprised, therefore, to find that in each case I was finding that git
was the winner.
This is only the first draft, so it's not very pretty; given that I now think
it's fairly pointless, I doubt very much that there will be a second draft.
However, before I consign it to the waste bin; I thought I'd share what I had
in case someone here had a use for it.
Executive summary: for the subset of features that git supplies that would
make it a subversion replacement; the UI for git is broadly compatible and
mostly better. The areas that make git look scary are:
- git-clone
- git-checkout
- git-help
- "svn cat" is missing from git
- git-ls-tree
- git-fsck-objects/git-repack/git-prune
- "svn revert" is missing from git
As always, please take the following with liberal amounts of IMHO.
---------------------------------
Subversion Versus Git
=====================
Andy Parkins <andyparkins@gmail.com>
Introduction
------------
Git is often accused of having a difficult user interface. I had
imagined that was the case too. I decided to write this comparison to
show the areas for which a simple version control system (like
subversion) had got the user interface right, and git had it wrong.
I was surprised to find that the areas of difficulty were a lot fewer
than I had expected. There is no reason why a user familiar with
subversion couldn't quickly cope with git's commands. I realised I had
been looking at Subversion through rose-tinted glasses. For the set of
features that Subversion supports, git is just as easy to use - if not
easier.
Note that this comparison is not of features, but of interface. Git
easily wins in terms of features. When it comes to using the more
advanced features of git, for which there is no Subversion equivalent,
then obviously there will be things to be learned. This comparison
however is limited to the subset of features of git that would make it
as near an equivalent to subversion as possible.
Comparison
----------
svn add::
Put files and directories under version control, scheduling them for
addition to repository. They will be added in next commit. This
doesn't really add anything, it just schedules.
git add::
Add files to the index file. This command does not simply schedule. It
takes the current contents of the file and copies it to the git staging
area.
The git index makes this command more complicated for git; however git
is using the verb "add" more correctly. In the subversion case, nothing
is actually added to a repository, it is merely scheduled for addition.
Although one could argue that by its nature, everything in subversion is
merely scheduling the action. Subversion being inherently simpler,
makes this easier to understand for the subversion user.
svn blame::
Output the content of specified files or URLs with revision and author
information inline.
git blame::
Show what revision and author last modified each line of a file.
This one is a draw. However, in terms of output, git is signficantly
better, it is much more intelligent about renames and copies and is much
faster.
svn cat::
Output the contents of specified files or URLs. Optionally at a
specific revision.
git cat-file -p $(git-ls-tree $REV $file | cut -d " " -f 3 | cut -f 1)::
git-ls-tree lists the object ID for $file in revision $REV, this is cut
out of the output and used as an argument to git-cat-file, which should
really be called git-cat-object, and simply dumps that object to stdout.
Subversion wins. This is a distinctly non-user friendly way of reading
a file.
svn checkout::
Checkout a working copy from a repository. You may check out an
arbitrary revision.
git clone::
git checkout::
Git, of course, is different from subversion, as the whole repository is
always available. git-checkout is nearest in concept to svn-checkout
though. It changes the current working directory to a particular
branch. You may not checkout an arbitrary revision. git-clone might
also be considered as an svn checkout analog. However,
Subversion wins. The output from Subversion's checkout is clear. The
output from git-clone gives output that is only understandable by
someone familiar with git internals.
svn cleanup::
Recursively clean up the working copy, removing locks, resuming
unfinished operations, etc.
git fsck-objects::
git prune::
git repack::
Check the repository for consistency, remove unreferenced objects, or
recompress existing objects.
They don't really serve the exact same purpose, but they are all
maintenance commands.
Subversion wins, as it only has one command and you don't need to
understand the repository in order to understand what its doing.
svn commit::
Pushes changes to the upstream respository from your working copy.
git commit -a::
Saves changes to the working copy as a new revision in the local
repository.
The need for "-a" (or not) because of git's staging area (the index)
here makes it more confusing than svn-commit for new users. However,
the ability to do "git --amend" more than makes up for it. Fixing a
typo in your last log message is difficult in subversion. Also, git's
commit message template is much better: both uses the output of their
status commands which is far clearer in git than in Subversion.
Git wins.
svn copy::
Duplicate something in working copy or repository, remembering history.
cp A B; git add B::
Git doesn't have a direct equivalent of svn copy. It's arguable whether
it needs it once the user knows they can git-add so easily.
Git wins. Git's ability to detect copies after-the-fact, mean that a
git-copy isn't necessary.
svn delete::
Remove files and directories from version control.
git rm::
Remove files from the working copy and the staging area.
Git wins. Git wins this because it doesn't need the git-rm at all. It
notices when a file has been removed anyway in git-commit -a; so for
this comparison, we can say that git-rm is not needed. For more complex
cases, were a user wants to remove a file from version control, but not
from disk, git-rm might be needed.
svn diff::
Display the differences between two paths. Defaults to showing the
differences between HEAD and the working copy.
git diff::
As for svn; but is arguably more powerful. It also has the distinct
advantage that it colourises its output, making it much easier to read.
Git wins. More powerful functionality available, but its default output
is fine as it is.
svn export::
Create an unversioned copy of a tree.
git archive::
Creates an archive of the files in the named tree.
Git wins. It can make zip/tar directly and add directory prefixes
should you want them. It could perhaps be a modicum easier if it had a
default output format so that "git-archive HEAD" would do something.
svn help::
git help::
Both of these operate in the same way, so this one will be judged on
utility of the output.
Subversion wins. The output from subversion often fits on a single
screen, and is merely there to give a reminder of what each option does.
git help simply forwards the user to a man page; which is very thorough,
but usually more than you need for a quick reference.
svn import::
Commit an unversioned file or tree into the repository.
git-init-db; git-add::
Git doesn't import external trees. Mainly because it doesn't need to.
Any directory can be quickly turned into a repository because
git-init-db and git-add are so fast. It can easily be turned back
because git only keeps one special directory (".git") at the top of the
working tree whereas subversion keeps one ".svn" directory per working
directory. Conversely, there is no way in subversion to adopt an
existing directory structure. It must be imported then checked out
somewhere else.
Git wins. It's fast and simple. There is only the most minimal change
to the users working tree.
svn info::
Display information about a local or remote item.
[no git equivalent]::
Apart from manually running git-log, git-show, git-diff, etc. There is
no way to get the simple summary that subversion provides about a given
item.
svn list::
List directory entries in the repository. Showing an arbitrary revision
if wanted.
git ls-tree::
Lists the content of a tree object.
Subversion wins. The output of git-ls-tree is not user friendly; it
requires some understanding of git internals.
svn lock::
svn unlock::
Lock working copy paths in the repository so that no other user can
commit changes to them.
[no git equivalent]::
Git can't do this; nor should it. Your repository is your own so there
is no point in locking any part of it.
Git wins. Being distributed makes this function unnecessary in git.
This makes one less command to learn.
svn log::
Show the log messages for a set of revision(s) and/or file(s).
git log::
Show commit logs.
Git wins. The log command is equally as simple to use, but git supports
more output formats (--pretty=online I find particularly useful). It
also colours it and formats it for much easier viewing. It can also
accept much more human-convenient filters (git log --since="2 weeks
ago").
svn merge::
Apply the differences between two sources to a working copy path.
git pull::
Pull and merge from another repository or a local branch.
It could be argued that "pull" is a bad name for this command. Apart
from that however, git-pull is significantly easier to use than svn
merge. It's output isn't as easy to understand, as it dumps loads of
confusing information to the user.
Git wins. Once you've used it, it's nowhere near as terrifying to use,
because it can be easily undone. It's harder to do damage because git
tracks merges whereas svn doesn't. It's better at merging. You will
spend a good five minutes thinking about what you must type for an
svn-merge. git-pull is a no-brainer.
svn mkdir::
Create a new directory under version control.
[no git equivalent]::
Git doesn't track directories, so doesn't need this command. Simply
adding content that is in a subdirectory is sufficient.
Git wins. It does the right thing for you and you needn't remember to
wrap your "mkdir"s with your VCS. Also, one-less-command.
svn move::
Move and/or rename something in working copy or repository.
git-mv::
Move or rename a file, directory or symlink.
Git wins. The two are equivalent except that git can do multiple moves
in one command, just like normal "mv". So "git mv src/* newsrc/" works
while "svn mv src/* newsrc/" doesn't. Additionally, if you forget to do
moves with git and instead use the command line, you can easily use
"update-index" to tell git about the move after the fact. In subversion
you have to undo all the moves and do them again with subversion. This
makes it inconvenient to use tools like "rename" to do regexp moves.
svn resolved::
Remove 'conflicted' state on working copy files or directories.
git update-index::
git checkout::
Git doesn't have a direct "resolved"; after you fix conflicts, you push
the changes into the staging area with "git-update-index".
Alternatively you can simply accept the version in HEAD by checking out
that version.
Draw. "svn-resolved" is rubbish, as it doesn't do any checks, it just
removes the conflict markers. Git could do with something that makes
life easier than understanding the index.
svn revert::
Restore pristine working copy file (undo most local edits).
git reset --hard::
Reset the repository to an arbitrary point in the past, updating the
working copy as well.
git checkout -f HEAD <file>::
Checks out <file> from HEAD, forcing an overwrite of any working
directory changes to that file.
Draw. There is no easy way to undo changes that have already been
committed to a subversion repository, so git would win. However, it's
uncomfortable to revert a single file using checkout.
svn status::
Print the status of working copy files and directories.
git status::
Show working tree status.
Git wins. Git's status output is colorised and doesn't rely on you
remembering single letter codes for file status. Instead is arranges
the changes in sections and describes the status in English. It shows
renames clearly, and sorts the file list instead of leaving it in a
random order (which makes it difficult to find particular files).
svn switch::
Update the working copy to a different URL.
[no git equivalent]::
git is distributed and can fetch from any number of remote repositories.
The URL can be typed on the command line of git-fetch, or can be given a
shortcut as a "remote". If we're talking about a single repository
(which we have to to compare against subversion), the repository is
local anyway.
Git wins. Command is unnecessary.
svn update::
Bring changes from the repository into the working copy.
git fetch; git pull::
git-fetch synchronises a tracking branch with a remote repository. Git
pull can be used to merge those changes into your working branch.
Git wins. The ability to track an upstream repository in a separate
branch, without having to merge until you're ready is a boon. The
commands "git-fetch" and "git-pull" are badly named, but the fact that
they are separate functions makes it far less traumatic to regularly run
"git-fetch" than "svn update".
[no svn equivalent]::
git ls-files::
Information about files in the index/working directory.
Git wins. git-ls-files can show modified files, tracked files, ignored
files, deleted files, untracked files - all in a format that is easily
piped to other commands.
Discussion
----------
What would git need to do to win in every section?
Subversion won:
- svn cat: the git equivalent is too complicated.
It wouldn't be hard to write a git-cat; if git's aliases allowed
pipes, it could be done instantly.
- svn checkout: the output from git-clone is unfriendly.
-------------------
remote: Generating pack...
remote: Done counting 6 objects.
remote: Deltifying 6 objects.
remote: 100% (6/6) done
Indexing 6 objects.
remote: Total 6, written 6 (delta 0), reused 0 (delta 0)
100% (6/6) done
-------------------
What are "objects"? What is deltifying? Why does object count
matter to me? What is indexing? How much data was transferred? How
long did it take? How big is my local clone?
While transferring: how long is it going to take to finish? How much
data is there to transfer in total?
- svn list: this only wins because the default output of git-ls-tree is
so user unfriendly.
- svn cleanup: git-fsck-objects, git-prune and git-repack all need too
specific knowledge of git.
They also need running too often on the user's initiative. It would
be nice, for example, if git-reset, git-rebase and git-branch could
detect when a prune is going to be needed and give the user a hint.
As to git-repack and git-fsck-objects - when _should_ these be run?
How is the user meant to know?
- svn help: subversion only won this because the help for almost every
command fits on a page. Git commands have so many options that need
such a lot of explanation that it's almost impossible to think of a
way that this problem could be solved.
Git draws with Subversion:
- svn resolved: Subversion only knows files are conflicted because they
are marked as such. git has good ways of detecting conflicting files
but has no interface around them. It would be nice to have a
git-resolve command that could pick "ours", "theirs" or "mine" and
update the index accordingly.
- svn revert: it's not easy to revert a single file in git; especially
once we bring the index into play. Restoring a single file in the index
to HEAD while leaving the rest of the index AND the working directory
untouched requires something like
----------------------------------------------------
git-ls-tree file | git-update-index --index-info
----------------------------------------------------
Which isn't simple enough for a typical user.
Conclusion
----------
Git is a perfectly adequate Subversion replacement. For a user who
would only want the features that they already have, they could surely
get to grips with the git UI quickly.
---------------------------------
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Catalin Marinas @ 2006-12-13 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vvekgl2z2.fsf@assigned-by-dhcp.cox.net>
On 13/12/06, Junio C Hamano <junkio@cox.net> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Unify the handling for cases C (add/add) and D (modify/modify).
> >
> > On Tue, 12 Dec 2006, Junio C Hamano wrote:
> >
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > > > How about this: if there is an add/add conflict, we treat it
> > > > as if there _was_ an empty file, and we let the shiny new
> > > > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > > > the file from the index, adding both files with different
> > > > "~blabla" markers appended to their file names to the working
> > > > directory.
What is this new xdl_merge()? Is it a better replacement for diff3? In
this situation diff3 would actually show two confict parts, each of
them being the full file, with an empty ancestor.
> This fixes the behaviour in "both branches add the path
> differently" case. Previously merge-recursive did not create
> the working tree file, but now it does just like merge-resolve.
>
> Although I would feel very happy about this change, Catalin
> might want to be informed about potential interaction this
> change might have with his commit 8d41555 in StGIT.
I don't think it affects StGIT. Previously, "git-read-tree -m" left a
file in the tree in this conflict situation. When I switched to
git-merge-recursive (to handle renames better), I noticed that the
file was no longer there and my merge algorithm failed. It now checks
whether the file is missing and it generates one.
The way StGIT handle any conflicts is not to leave the index in a
state with multiple stages per file. When I push a patch that is
causing an add/add situation, I want a version of the file to be added
to the index (usually the one already in the tree, not in the patch
being pushed) so that a "stg status" won't show like the patch is
removing that file.
--
^ permalink raw reply
* Re: [RFC] requiring Perl SVN libraries for git-svn
From: Randal L. Schwartz @ 2006-12-13 21:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061213202142.GE8179@localdomain>
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> The API of the SVN:: libraries seem to be relatively stable these days
Eric> and are *much* faster than the command-line client. I plan on
Eric> maintaining compatibility with version 1.1 of the SVN libraries for at
Eric> least another year; or more if it's not a big problem.
For a while, I would have been upset. I was building SVN from fink, even
though I was using a private Perl as /usr/local/bin/perl. And since the Perl
bindings have to be built when the SVN package is built, it was being built
against the core Perl, which I didn't use, so I couldn't use the SVN bindings.
Now, I'm building SVN from darwinports, which builds its own Perl, and I have
~/bin/git-svn wrap the /opt/git/bin/git-svn passing it the /opt/local/bin/perl
instead of the first Perl in the path. And it all just works. I suppose
I could have done that before too. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* What's cooking in git.git
From: Junio C Hamano @ 2006-12-13 21:38 UTC (permalink / raw)
To: git
I think the last issue in "consolidated topic listing" format
was a success, so this is in the same format. In the following
listing, a commit in 'next' has '+' in front, and the ones only
in 'pu' have '-' in front. The date after each topic name is
the last time the topic was touched.
* jc/diff--cached (Wed Dec 13 01:33:43 2006 -0800) 1 commit
+ Revert "git-diff: Introduce --index and deprecate --cached."
Will merge to 'master' shortly and will be in v1.5.0.
* jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
- git-add --interactive: hunk splitting
- git-add --interactive
Undecided. Either drop it altogether or merge it to 'next'
after adding 'edit' interface to the index contents.
* jn/web (Sun Dec 10 13:25:49 2006 +0100) 5 commits
+ gitweb: SHA-1 in commit log message links to "object" view
+ gitweb: Hyperlink target of symbolic link in "tree" view (if
possible)
+ gitweb: Add generic git_object subroutine to display object of any
type
+ gitweb: Show target of symbolic link in "tree" view
+ gitweb: Don't use Content-Encoding: header in git_snapshot
Haven't looked at them fully, but likely to be in v1.5.0.
* jc/blame-boundary (Fri Dec 1 20:45:45 2006 -0800) 1 commit
+ git-blame: show lines attributed to boundary commits differently.
This does not break gitweb nor git-cvsserver because they have
no way to specify boundary commits. Likely to be in v1.5.0.
Later we can update gitweb to allow specifying the range and
handle 'boundary' annotations in a special way.
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
We probably should come up with a unified way to allow various
commands that can leave the working tree into special states to
communicate with each other first. Will NOT be in v1.5.0.
* jc/patch-inline-comments (Fri Dec 8 21:03:52 2006 -0800) 1 commit
- mailinfo: hack to accept in-line annotations in patches.
Will drop.
* sv/git-svn (Tue Dec 5 16:17:38 2006 +1100) 5 commits
- git-svn: re-map repository URLs and UUIDs on SVK mirror paths
- git-svn: collect revision properties when fetching
- git-svn: collect SVK source URL on mirror paths
- git-svn: let libsvn_ls_fullurl return properties too
- git-svn: make test for SVK mirror path import
Sam Villain's SVN fixes are queued in 'pu' but the series hasn't
seen updates after Eric commented on them. Still on hold.
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
This does the magic unconditionally which I am not 100% happy
about, because the resulting mess could be too large to handle.
On the other hand, the user deserves what he gets if he starts a
merge from wildly unclean state, so it may not be too much of an
issue. Undecided.
* jc/leftright (Sun Oct 22 17:32:47 2006 -0700) 1 commit
- rev-list --left-right
I think this needs a better UI integration into 'git log' and
friends, not just rev-list. Currently, I can say:
$ git rev-list --no-merges --left-right --pretty v1.4.4.2...master
but that still misses --stat and --patch output. If people find
this useful, maybe we would want to merge it to 'next' after
adding the option to log and friends (or turn it on
automatically when symmetric difference is used).
* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
+ fetch-pack: Do not fetch tags for shallow clones.
+ get_shallow_commits: Avoid memory leak if a commit has been
reached already.
+ git-fetch: Reset shallow_depth before auto-following tags.
+ upload-pack: Check for NOT_SHALLOW flag before sending a shallow
to the client.
+ fetch-pack: Properly remove the shallow file when it becomes
empty.
+ shallow clone: unparse and reparse an unshallowed commit
+ Why didn't we mark want_obj as ~UNINTERESTING in the old code?
+ Why does it mean we do not have to register shallow if we have
one?
+ We should make sure that the protocol is still extensible.
+ add tests for shallow stuff
+ Shallow clone: do not ignore shallowness when following tags
+ allow deepening of a shallow repository
+ allow cloning a repository "shallowly"
+ support fetching into a shallow repository
+ upload-pack: no longer call rev-list
The 'shallow clone'. Most likely post v1.5.0.
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
If somebody steps up to maintain the gitweb installation at
kernel.org, merging this would make one less thing to customize
there. Undecided.
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
This is developer-only; will hold.
* jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
- para-walk: walk n trees, index and working tree in parallel
Backburnered and will continue to hold. I suspect unpack-trees
logic that is used by read-tree would turn out to be too
cumbersome to optimize and at that point this might become
useful.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
Will hold until February.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2006-12-13 21:35 UTC (permalink / raw)
To: git; +Cc: linux-kernel
We have a handful fixes on 'maint'; I will be cutting v1.4.4.3 by
the end of the week.
On the 'master' front, this round has many topics (most of which
have been cooking in the 'next' branch) merged since the last
announcement.
- Johannes Schindelin's built-in shortlog is in.
- Johannes Schindelin's built-in 'RCS merge replacement' is
in. Hopefully this would make merge-recursive more portable
and faster.
- Shawn Pearce and Johannes Schindelin spotted and fixed a few
corner cases in merge-recursive.
- Updates to gitk from Paul Mackerras to fix longstanding menu
issues on Mac OS X.
- Eric Wong fixed use of rerere in many places.
- Eric also has quite a few fixes to git-svn.
- Nico updated 'git-add' to really mean 'add contents', not
'add to the set of tracked paths'. Also updated was the
documentation for 'git commit' to make it easier to teach new
people after a long discussion.
- Lars Hjemli taught 'git-branch' to rename branches.
- Andy Parkins taught 'git-branch' to be colorful.
- Robin Rosenberg improved cvsexportcommit for unusual
pathnames.
- 'git push $URL :refs/tags/that' (notice the colon) can be
used to delete 'that' tag from the remote repository; this
needs the latest git on both ends.
- branch."master".{remote,merge} configuration items are set up
by 'git-clone', thanks to Andy Parkins.
- 'git-commit' gives 'diff --summary' output to remind mode
changes and added/deleted files.
- 'git-diff --numstat' matches 'git-apply --numstat' when
talking about binary changes.
- 'git-merge' is now a first class UI, not just a mere driver
for strategies.
I am hoping that we can start a stabilization cycle for v1.5.0
based on what we have in 'master'. The theme is "usability and
teachability".
Things that need to be done to complete what have been merged to
'master' are:
- 'git-rm' needs to be fixed up as Linus outlined; remove
working tree file and index entry but have a sanity check to
make sure the working tree file match the index and HEAD.
- 'git-branch' may need to be taught about renaming the
matching per-branch configuration at the same time.
- 'git-merge-file' needs to be documented and linked from
git.txt.
- 'git-clone' probably should be updated to use wild-card in
remote.origin.fetch, instead of listing all the branches it
found when the clone was made.
- tutorials and other Porcelain documentation pages need to be
updated to match the updated 'git-add' and 'git-rm' (to be
updated), and their description should be made much less
about implementation; they should talk in terms of end-user
workflows. I will send a draft for 'git diff' out later, but
somebody needs a full sweep on Porcelain-ish documentation.
- 'git diff --index' patch should be reverted (already done in
'next'), although we may have to come up with a better
wording for --cached.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.4.4.2.
Alex Riesen (1):
Clarify fetch error for missing objects.
Brian Gernhardt (1):
Move Fink and Ports check to after config file
Chris Wright (1):
no need to install manpages as executable
Eric Wong (2):
git-svn: exit with status 1 for test failures
git-svn: correctly display fatal() error messages
Jim Meyering (1):
Don't use memcpy when source and dest. buffers may overlap
Martin Langhoff (1):
cvsserver: Avoid miscounting bytes in Perl v5.8.x
Shawn O. Pearce (1):
Make sure the empty tree exists when needed in merge-recursive.
* The 'master' branch has these since the last announcement.
Alex Riesen (3):
git-blame: fix rev parameter handling.
Make perl/ build procedure ActiveState friendly.
Clarify fetch error for missing objects.
Andreas Ericsson (2):
ls-files: Give hints when errors happen.
git-diff: Introduce --index and deprecate --cached.
Andy Parkins (6):
Use .git/config for storing "origin" shortcut repository
Document git-repo-config --bool/--int options.
De-emphasise the symbolic link documentation.
Explicitly add the default "git pull" behaviour to .git/config on clone
Colourise git-branch output
Allow subcommand.color and color.subcommand color configuration
Brian Gernhardt (1):
Move Fink and Ports check to after config file
Chris Wright (1):
no need to install manpages as executable
David Miller (1):
Pass -M to diff in request-pull
Eric Wong (21):
git-svn: use ~/.subversion config files when using SVN:: libraries
git-svn: enable delta transfers during fetches when using SVN:: libs
git-svn: update tests for recent changes
git-svn: error out when the SVN connection fails during a fetch
git-svn: fix output reporting from the delta fetcher
git-svn: color support for the log command
git-svn: documentation updates
git-svn: fix multi-init
git-svn: avoid fetching files twice in the same revision
git-svn: avoid network timeouts for long-running fetches
git-svn: extra error check to ensure we open a file correctly
git-svn: use do_switch for --follow-parent if the SVN library supports it
rerere: add clear, diff, and status commands
rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am
git-svn: enable logging of information not supported by git
git-svn: allow dcommit to take an alternate head
git-svn: correctly display fatal() error messages
git-svn: correctly handle packed-refs in refs/remotes/
git-svn: exit with status 1 for test failures
git-svn: correctly display fatal() error messages
git-svn: correctly handle "(no author)" when using an authors file
Han-Wen Nienhuys (1):
ident.c: Trim hint printed when gecos is empty.
J. Bruce Fields (4):
cvs-migration: improved section titles, better push/commit explanation
Documentation: reorganize cvs-migration.txt
Documentation: update git-clone man page with new behavior
Documentation: simpler shared repository creation
Jakub Narebski (4):
gitweb: Fix Atom feed <logo>: it is $logo, not $logo_url
git-clone: Rename --use-immingled-remote option to --no-separate-remote
Document git-diff whitespace flags -b and -w
gitweb: Allow PNG, GIF, JPEG images to be displayed in "blob" view
Jeff King (1):
shortlog: fix segfault on empty authorname
Jim Meyering (2):
Set permissions of each new file before "cvs add"ing it.
Don't use memcpy when source and dest. buffers may overlap
Johannes Schindelin (18):
Build in shortlog
shortlog: do not crash on parsing "[PATCH"
shortlog: read mailmap from ./.mailmap again
shortlog: handle email addresses case-insensitively
shortlog: fix "-n"
shortlog: use pager
sha1_object_info(): be consistent with read_sha1_file()
xdiff: add xdl_merge()
xdl_merge(): fix an off-by-one bug
xdl_merge(): fix thinko
git-mv: search more precisely for source directory in index
diff -b: ignore whitespace at end of line
xdl_merge(): fix and simplify conflict handling
cvs-migration document: make the need for "push" more obvious
Add builtin merge-file, a minimal replacement for RCS merge
merge-file: support -p and -q; fix compile warnings
Get rid of the dependency on RCS' merge program
merge-recursive: add/add really is modify/modify with an empty base
Josef Weidendorfer (1):
Add branch.*.merge warning and documentation update
Junio C Hamano (45):
Store peeled refs in packed-refs file.
remove merge-recursive-old
git-merge: make it usable as the first class UI
merge: allow merging into a yet-to-be-born branch.
Store peeled refs in packed-refs (take 2).
git-fetch: reuse ls-remote result.
git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
git-fetch: allow glob pattern in refspec
Allow git push to delete remote ref.
git-shortlog: fix common repository prefix abbreviation.
git-shortlog: make common repository prefix configurable with .mailmap
git-commit: show --summary after successful commit.
git-fetch: allow forcing glob pattern in refspec
fetch-pack: do not barf when duplicate re patterns are given
git-merge: tighten error checking.
git-merge: do not leak rev-parse output used for checking internally.
cvsimport: style fixup.
git blame -C: fix output format tweaks when crossing file boundary.
tutorial: talk about user.name early and don't start with commit -a
git-merge: fix confusion between tag and branch
xmerge: make return value from xdl_merge() more usable.
merge-recursive: use xdl_merge().
receive-pack: do not insist on fast-forward outside refs/heads/
unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
read-tree: further loosen "working file will be lost" check.
Loosen "working file will be lost" check in Porcelain-ish
read-tree: document --exclude-per-directory
git-reset to remove "$GIT_DIR/MERGE_MSG"
git-merge: squelch needless error message.
git-merge: fix "fix confusion between tag and branch" for real
Fix perl/ build.
git-rerere: add 'gc' command.
Documentation/git-commit: rewrite to make it more end-user friendly.
git-commit: allow --only to lose what was staged earlier.
shortlog: remove "[PATCH]" prefix from shortlog output
shortlog: fix segfault on empty authorname
diff --numstat: show binary with '-' to match "apply --numstat"
add test case for recursive merge
git-push: document removal of remote ref with :<dst> pathspec
git merge: reword failure message.
spurious .sp in manpages
git-push: accept tag <tag> as advertised.
send-pack: tighten checks for remote names
branch --color: change default color selection.
config documentation: group color items together.
Lars Hjemli (3):
git-branch: add options and tests for branch renaming
rename_ref: use lstat(2) when testing for symlink
git-branch: let caller specify logmsg
Martin Langhoff (1):
cvsserver: Avoid miscounting bytes in Perl v5.8.x
Michael Loeffler (1):
git-fetch: ignore dereferenced tags in expand_refs_wildcard
Nicolas Pitre (4):
builtin git-shortlog is broken
pack-objects: remove redundent status information
make 'git add' a first class user friendly interface to the index
change the unpack limit treshold to a saner value
Paul Mackerras (1):
gitk: Fix enabling/disabling of menu items on Mac OS X
René Scharfe (1):
shortlog: remove range check
Robin Rosenberg (1):
Make cvsexportcommit work with filenames with spaces and non-ascii characters.
Sean Estabrooks (1):
Update documentation to remove incorrect GIT_DIFF_OPTS example.
Shawn O. Pearce (17):
Teach git-completion.bash how to complete git-merge.
Hide plumbing/transport commands from bash completion.
Teach bash how to complete options for git-name-rev.
Add current branch in PS1 support to git-completion.bash.
Teach bash how to complete git-format-patch.
Teach bash how to complete git-cherry-pick.
Teach bash how to complete git-rebase.
Teach bash about git log/show/whatchanged options.
Support bash completion of refs/remote.
Teach bash about git-repo-config.
Support --strategy=x completion in addition to --strategy x.
Cache the list of merge strategies and available commands during load.
Teach bash about git-am/git-apply and their whitespace options.
Teach bash how to complete long options for git-commit.
Fix broken bash completion of local refs.
Make sure the empty tree exists when needed in merge-recursive.
Remove uncontested renamed files during merge.
Uwe Zeisberger (1):
Fix documentation copy&paste typo
^ permalink raw reply
* Re: More merge-recursive woes
From: Shawn Pearce @ 2006-12-13 20:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612131526180.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 13 Dec 2006, Shawn Pearce wrote:
>
> > Bug #1: If one branch renames a file which existed in the merge base,
> > when we merge that change into a different branch the old version of the
> > file is not deleted from the working directory. The attached test
> > script shows this ("BAD: A still exists in working directory").
>
> You miss a ":" at the end of the test script, BTW.
>
> This bug is fixed by your patch, which makes remove_file() update the
> working directory in the last stage.
Yes; and if you noticed this message got hung up in the email
system while I found the bug, fixed the bug, and replied to your
correction of the fix. And I also fixed the test script along
the way. Silly email systems holding messages. *sigh*
> > Bug #2: In that horrible repository that I have where I ran into the
> > empty tree missing bug I now have a pair of commits which when merged
> > together cause git-merge-recursive to go into an infinite loop,
> > or least burn CPU for hours on end without doing squat. I have
> > not been able to get enough data to even write a good analysis
> > of it yet. I'll try to do that this week, as I cannot share the
> > repository itself. It just happens to be two new commits along
> > the same two branches however. :-(
>
> Could you please send me the rev-list output for this test case?
I'm actually going to go back in later tonight to try and figure
this one out. Whatever data I get I'll be sure to include the
rev-list --parents output from this case as well; unless I can
craft a really small test case which causes the same infinite loop.
--
^ permalink raw reply
* [RFC] requiring Perl SVN libraries for git-svn
From: Eric Wong @ 2006-12-13 20:21 UTC (permalink / raw)
To: git
Are there any git-svn users out there who would be seriously hurt if I
dropped support for using the svn command-line client in git-svn?
The API of the SVN:: libraries seem to be relatively stable these days
and are *much* faster than the command-line client. I plan on
maintaining compatibility with version 1.1 of the SVN libraries for at
least another year; or more if it's not a big problem.
Lately, I've introduced support for authentication and connecting to
repositories with limited read permissions, as well as reading from the
config files in ~/.subversion; so everything that could be done with
the command-line client backend can be done with the libraries, too.
--
^ permalink raw reply
* Average size of git bookkeeping data (related to Using git as a general backup mechanism)
From: David Tweed @ 2006-12-13 19:31 UTC (permalink / raw)
To: git
Hi,
This is in connection with the "Using git as a general backup mechanism" thread,
but on a different slant more along automatic versioning a subset of the files on the disc (to avoid
sucking in things like core files and particularly huge multimedia files). In this case I don't
want to discard old "backups" but just grow the chronological database. (Think a more selective version of
Plan 9's venti filesystem.)
How big is the "metadata" or "bookeeping data" in git related to a commit? (Eg, "around x bytes per changed file"
or "around x bytes per file being tracked (whether changed in the commit or not)" )
[I'm trying to get a feel for, if I switched to git, how much overhead would come from having a cron job automatically doing
a snapshot every hour (if anything has changed), plus manual snapshots at points where I want to feel "safeguarded".
I'm currently using my own simple, hacked together system for combined versioning/backups that does
this. Using naive tools that don't account for wastes space due to disk block size effects the data being
tracked is currently just under 9 months of acitvity on 2016 filenames with
17457599 bytes of data (ie, compressed version of their contents at various times) and 7838546 bytes
is "metadata", ie, 30 percent of the stored data is metadata. This is in a format using 6 bytes to associate a single blob of
contents to a filename (whether changed since last snapshot or not).]
Many thanks for any insight,
cheers, dave tweed
^ permalink raw reply
* Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)
From: Daniel Barkalow @ 2006-12-13 18:10 UTC (permalink / raw)
To: Kyle Moffett; +Cc: git
In-Reply-To: <8900B938-1360-4A67-AB15-C9E84255107B@mac.com>
On Tue, 12 Dec 2006, Kyle Moffett wrote:
> Hmm, ok. It would seem to be a reasonable requirement that if you want to
> change any of the "preserve_*_attributes" config options you need to blow away
> and recreate your index, no? I would probably change the underlying index
> format pretty completely and stick a new version tag inside it.
You should be able to promote an insufficient-version index to a
new-version index that's needs to be refreshed for every entry. (And then
update-index would take care of the necessary rewrite-everything in the
normal way). But I suspect that the right thing is to require that the
repository be created with a "commits-include-directories-not-trees" flag,
and this means that you always use the extra-detailed index, and the
options only affect what information is filtered out in transit between
the directory object and the index. Having more information in the index
is merely a potential waste of space, not a correctness issue (we have
extra information for trees in the index now, remember); it just means
that there are more things that will cause git to reread the file, rather
than declaring it unchanged with a stat().
For that matter, it may be best for the directory objects to record what
information in them is real, and keep the "what's content" mask in the
index as well. If it changes over the history of a repository, you want to
correctly interpret the historical commits.
> Ok, seems straightforward enough. One other thing that crossed my mind was
> figuring out how to handle hardlinks. The simplest solution would be to add
> an extra layer of indirection between the "file inode" and the "file data".
> Instead of your directory pointing to a "file-data" blob and "file-attributes"
> object, it would point to an "file-inode" object with embedded attribute data
> and a pointer to the file contents blob.
>
> I remember reading some discussions from the early days of GIT about how that
> was considered and discarded because the extra overhead wouldn't give any real
> tangible benefit. On the other hand for something like /etc the added
> benefits of tracking extended attributes and hardlinks might outweigh the cost
> of a bunch of extra objects in the database. A bit of care with the
> construction of the index file should make it sufficiently efficient for
> day-to-day usage.
I was thinking this could be internal to the directory object, but you
probably want to support hardlinks shared between dentries in different
directory objects, so you're probably right that this makes sense.
Alternatively, you could use a single "directory" object for the whole
state (including subdirectories), making hardlinks out of the object
clearly impossible, or you could use some scheme for sharing
sub-"directory" objects that would imply that hardlinks are within an
object (the hard part here is finding things when their locations aren't
predictable by name).
-Daniel
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Daniel Drake @ 2006-12-13 16:28 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
In-Reply-To: <20061211204904.GC1003@sashak.voltaire.com>
On Mon, 2006-12-11 at 22:49 +0200, Sasha Khapyorsky wrote:
> Maybe I'm starting to understand. Your svn url (url which points to svn
> repository) is https://server/repo and not just https://server, right?
>
> If so, please remove the patch (you don't need it) and rerun:
>
> git-svnimport -v -i -C repo -r https://server/repo
Sorry, apparently I was using the wrong git-svnimport in my last mail.
The above command, with or without your svn_dir patch, doesn't solve the
problem.
With your patch:
# git-svnimport -v -i -C repo -r https://server/repo
RA layer request failed: PROPFIND request failed on '/trunk/.cvsignore':
PROPFIND of '/trunk/.cvsignore': 405 Method Not Allowed (https://svn) at
git-svnimport line 364
# git-svnimport -v -i -C repo -r https://server repo
perl: subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion
`is_canonical (path, len)' failed.
Aborted
Without the patch, the error is the same as the 1st case in both
situations.
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Johannes Schindelin @ 2006-12-13 16:39 UTC (permalink / raw)
To: Florian v. Savigny; +Cc: git
In-Reply-To: <0MKwpI-1GuWVF2znk-0006fC@mrelayeu.kundenserver.de>
Hi,
On Wed, 13 Dec 2006, Florian v. Savigny wrote:
> I would like to use git to develop a somewhat larger Perl project
> which I would need to test and develop under both Linux and Windows,
> i.e. I would need a repository on a FAT32 partition (to my knowledge,
> still the only filesystem that can be fully accessed from both OSes -
> correct me if I'm wrong) which could be accessed by two compatible git
> executables, such that I could switch back and forth.
I would not use the _same_ repository from both Windows and Linux, but
rather fetch/push from/to the Windows partition.
I am using Cygwin to compile git, and I have a USB Stick with FAT32 on
which I push regularly. Important: since Linux is more intelligent about
permissions, I had to initialize the repos with Windows.
To get started compiling, you might want to use the autoconf script.
Ciao,
Dscho
^ permalink raw reply
* Can git be tweaked to work cross-platform, on FAT32?
From: Florian v. Savigny @ 2006-12-13 15:58 UTC (permalink / raw)
To: git
Hi there,
I would like to use git to develop a somewhat larger Perl project
which I would need to test and develop under both Linux and Windows,
i.e. I would need a repository on a FAT32 partition (to my knowledge,
still the only filesystem that can be fully accessed from both OSes -
correct me if I'm wrong) which could be accessed by two compatible git
executables, such that I could switch back and forth.
Before describing how I (unsuccessfully, which is perhaps not
surprising, as I'm C-illiterate) hacked the Makefile to compile two
git siblings, I would like to generally ask whether this is possible
at all (or should be possible in theory, in which case I'm willing to
test extensively), whether with Cygwin or not. The preliminary
impression was that the Linux version would not accept a repository on
FAT32 (it did work with more Unixish filesystems). - I do not need the
networking capabilities, BTW (standalone development), if that is an
issue in any way.
Thanks for any hint!
Florian
--
Florian von Savigny
__________________________________________________________________
lorian@fsavigny.de
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Andreas Ericsson @ 2006-12-13 15:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Bahadir Balban, git, Andy Parkins
In-Reply-To: <Pine.LNX.4.63.0612131611050.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 13 Dec 2006, Andreas Ericsson wrote:
>
>> Junio C Hamano wrote:
>>> "Bahadir Balban" <bahadir.balban@gmail.com> writes:
>>>
>>> There is one thing we could further optimize, though.
>>>
>>> Switching branches with 100k blobs in a commit even when there
>>> are a handful paths different between the branches would still
>>> need to populate the index by reading two trees and collapsing
>>> them into a single stage. In theory, we should be able to do a
>>> lot better if two-tree case of read-tree took advanrage of
>>> cache-tree information. If ce_match_stat() says Ok for all
>>> paths in a subdirectory and the cached tree object name for that
>>> subdirectory in the index match what we are reading from the new
>>> tree, we should be able to skip reading that subdirectory (and
>>> its subdirectories) from the new tree object at all.
>>>
>>> Anybody interested to give it a try?
>>>
>> I'm not vell-versed enough in git internals to have my hopes high of
>> making something useful of it, but if you give me a pointer of where to
>> start I'd be happy to try, and perhaps learn something in the process.
>
> Okay, I'll have a stab at explaining it.
>
> For huge working directories, you usually have a huge number of trees. The
> idea of cache_tree is to remember not only the stat information of the
> blobs in the index, but to cache the hashes of the trees also (until they
> are invalidated, e.g. by an update-index). This avoids recalculation of
> the hashes when committing.
>
> This cache is accessible by the global variable active_cache_tree. It is
> best accessed by the function cache_tree_find(), which you call like that:
>
> struct cache_tree *ct = cache_tree_find(active_cache_tree, path);
>
> where the variable "path" may contain slashes. The SHA1 of the
> corresponding tree is in ct->sha1, and you can check if the hash is still
> valid by asking
>
> if (cache_tree_fully_valid(ct))
> /* still valid */
>
> AFAIU Junio would like to take the shortcut of doing nothing at all when
> (twoway) reading a tree whose hash is identical to the hash stored in the
> corresponding cache_tree _and_ when the cache is still fully valid.
>
Seems you wrote half the code for me already. :)
Thanks for the excellent explanation. I'll see if I can grok it further
tonight.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Johannes Schindelin @ 2006-12-13 15:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Bahadir Balban, git, Andy Parkins
In-Reply-To: <457FCA8C.6000300@op5.se>
Hi,
On Wed, 13 Dec 2006, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> > "Bahadir Balban" <bahadir.balban@gmail.com> writes:
> >
> > There is one thing we could further optimize, though.
> >
> > Switching branches with 100k blobs in a commit even when there
> > are a handful paths different between the branches would still
> > need to populate the index by reading two trees and collapsing
> > them into a single stage. In theory, we should be able to do a
> > lot better if two-tree case of read-tree took advanrage of
> > cache-tree information. If ce_match_stat() says Ok for all
> > paths in a subdirectory and the cached tree object name for that
> > subdirectory in the index match what we are reading from the new
> > tree, we should be able to skip reading that subdirectory (and
> > its subdirectories) from the new tree object at all.
> >
> > Anybody interested to give it a try?
> >
>
> I'm not vell-versed enough in git internals to have my hopes high of
> making something useful of it, but if you give me a pointer of where to
> start I'd be happy to try, and perhaps learn something in the process.
Okay, I'll have a stab at explaining it.
For huge working directories, you usually have a huge number of trees. The
idea of cache_tree is to remember not only the stat information of the
blobs in the index, but to cache the hashes of the trees also (until they
are invalidated, e.g. by an update-index). This avoids recalculation of
the hashes when committing.
This cache is accessible by the global variable active_cache_tree. It is
best accessed by the function cache_tree_find(), which you call like that:
struct cache_tree *ct = cache_tree_find(active_cache_tree, path);
where the variable "path" may contain slashes. The SHA1 of the
corresponding tree is in ct->sha1, and you can check if the hash is still
valid by asking
if (cache_tree_fully_valid(ct))
/* still valid */
AFAIU Junio would like to take the shortcut of doing nothing at all when
(twoway) reading a tree whose hash is identical to the hash stored in the
corresponding cache_tree _and_ when the cache is still fully valid.
Ciao,
Dscho
^ permalink raw reply
* Re: Using git-bisect to find more than one breakage
From: J. Bruce Fields @ 2006-12-13 14:34 UTC (permalink / raw)
To: n0dalus; +Cc: git
In-Reply-To: <6280325c0612112034x373c8022q909ca192a866cfcf@mail.gmail.com>
On Tue, Dec 12, 2006 at 03:04:29PM +1030, n0dalus wrote:
> This is what I tried to do:
> - Make a branch ("working") at the bad commit
> - Commit a patch to undo the bug-causing change from that commit
> - Make a copy of the master branch
> - git-rebase working
> - (Then if that worked, use git-bisect to find the next breakage)
>
> I expected git-rebase to just apply all the commits from the master
> onto my working branch, possibly stopping in the case of a conflict to
> the file I patched. Instead, it produces large conflicts with
> unrelated files, on the very first commit it tries to apply. I even
> get the conflicts if the commit I make before using git-rebase changes
> no files at all (just adding an empty file 'test').
>
> Is there something wrong with my method here? Is there another way to do
> this?
>
> I am thinking for now I will just use git-bisect between the bad
> commit and master, and apply my changes to every bisection.
Yes, that's the way to do it.
The git-rebase command is intended for rebasing small pieces of purely
linear history; I don't believe it will work well (at all?) to rebase a
large chunk of kernel history.
^ permalink raw reply
* Re: Using git-bisect to find more than one breakage
From: n0dalus @ 2006-12-13 15:06 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20061213143404.GA24132@fieldses.org>
On 12/14/06, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Tue, Dec 12, 2006 at 03:04:29PM +1030, n0dalus wrote:
> >
> > I am thinking for now I will just use git-bisect between the bad
> > commit and master, and apply my changes to every bisection.
>
> Yes, that's the way to do it.
>
> The git-rebase command is intended for rebasing small pieces of purely
> linear history; I don't believe it will work well (at all?) to rebase a
> large chunk of kernel history.
>
Yeah, I figured it couldn't deal with all the merges and stuff.
It'd be nice if the man page for git-rebase warned about it's
inability to handle lots of complex merges. Or if the git-bisect man
page mentioned that the easiest way to find more than one problem is
to find and fix the first, then apply that fix to every bisection
between that first problem and a known bad version.
Thanks though, now I can stop worrying about why the rebase wasn't
working and concentrate on finding the bugs.
^ permalink raw reply
* Re: More merge-recursive woes
From: Johannes Schindelin @ 2006-12-13 14:28 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061213073639.GA9289@spearce.org>
Hi,
On Wed, 13 Dec 2006, Shawn Pearce wrote:
> Bug #1: If one branch renames a file which existed in the merge base,
> when we merge that change into a different branch the old version of the
> file is not deleted from the working directory. The attached test
> script shows this ("BAD: A still exists in working directory").
You miss a ":" at the end of the test script, BTW.
This bug is fixed by your patch, which makes remove_file() update the
working directory in the last stage.
> Bug #2: In that horrible repository that I have where I ran into the
> empty tree missing bug I now have a pair of commits which when merged
> together cause git-merge-recursive to go into an infinite loop,
> or least burn CPU for hours on end without doing squat. I have
> not been able to get enough data to even write a good analysis
> of it yet. I'll try to do that this week, as I cannot share the
> repository itself. It just happens to be two new commits along
> the same two branches however. :-(
Could you please send me the rev-list output for this test case?
Ciao,
^ permalink raw reply
* Re: More Perl fun: man and System directories
From: Sebastian Harl @ 2006-12-13 13:14 UTC (permalink / raw)
To: git
In-Reply-To: <4F093D53-CFC7-44F1-9460-22DAD35DBAC8@silverinsanity.com>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
Hi,
On Wed, Dec 13, 2006 at 08:07:19AM -0500, Brian Gernhardt wrote:
> 1) Perl is creating man files in the wrong place. My system expects
> them to be in /usr/local/share/man, but Perl is installing them in /
> usr/local/man. Currently I'm just moving them by hand every time I
> pull-make-install, which is less than optimal.
Try "perl Makefile.PL INSTALLDIRS=vendor".
Cheers,
Sebastian
--
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT - releases workflow
From: Andreas Ericsson @ 2006-12-13 13:13 UTC (permalink / raw)
To: Sean Kelley; +Cc: Matthias Kestenholz, git
In-Reply-To: <89b129c60612130439m452b315x2278456396a248a5@mail.gmail.com>
Sean Kelley wrote:
> Hi,
>
> On 12/13/06, Sean Kelley <sean.v.kelley@gmail.com> wrote:
>> Hi,
>>
>> On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:
>> >
>> How do I push that tag that I created to the maint/v0.1 branch on the
>> remote repository?
>
> Never mind, I answered my own question. Sorry for asking without
> doing my research first.
>
> git push --tags origin
>
Sort of, but not quite. This will push *all* your tags to wherever
origin points to. If you, like me, use un-annotated tags to remember a
particular snapshot you will then push a number of tags named "foo",
"fnurg", "sdf" and "werwer" to the mothership repo.
git push origin v0.1
works marvellously though.
Btw, this behaviour of mine, coupled with the company policy of only
allowing annotated tags signed by the project maintainer as
release-tags, lead to the creation of the update-hook I believe is still
shipped as the default update-hook template with the git repo. It
disallows un-annotated tags completely and should be used on the
mothership repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ 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