* Getting rid of symlinks in .git?
From: Petr Baudis @ 2005-11-10 20:45 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
I'm deliberately breaking up the thread here, not to make the list
reading even more difficult for all the poor readers not so interested
in electronic archaeology (but I feel better after I began taking my
new meds, I can even resist this huge urge to start replying to mails
from June).
In-Reply-To: <1131653507.11283.31.camel@dv>
7261 N T Nov 10 Pavel Roskin ( 1.8K)
Re: [PATCH] cg-pull to stop treating "master" specially,
fix fetch_local for .git/HEAD
(deliberately quoted in entirety)
Dear diary, on Thu, Nov 10, 2005 at 09:11:47PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Thu, 2005-11-10 at 20:24 +0100, Petr Baudis wrote:
> > can you still remember why did you introduce this? In GNU cp
> > documentation, I can see just
> >
> > -b, --backup
> > Make backups of files that are about to be overwritten or removed.
> >
> > which doesn't make sense to me - -L dereferences symlinks.
>
> You are right, it must be my error. Anyway, it was so long ago that I
> would need to review and retest it.
Is it correct that all there is to it is to check if cloning locally
works properly with symlinked HEAD in the remote repository?
> While at that, let's stop using symlinks. git doesn't use symlinks on
> Cygwin. I think git should use that code on all OSes, since the
> benefits of using symlinks are minimal (I think the only benefits are
> their atomicity and resolving the reference in the kernel rather than in
> userspace). Having more uniform code for all platforms would simplify
> development and testing. It could also reduce requirements for the
> transport protocols. Finally, symlinks could be still used by the users
> (if they know what they are doing) - git and cogito would simply become
> symlink agnostic.
>
> When files are copied around, symlinks are pain to deal with. They
> require special handling to be preserved both for remote operation and
> dereferenced for local operation (that's what my patch was intended to
> do). I'm not even considering what would happen when cloning from Linux
> to Windows or vice versa.
I personally would not mind getting rid of symlinks completely, but we
will still have to support them for some reasonable time period (several
major releases, as far as Cogito is concerned - actually, there is
plenty of people still using 0.13 and such).
If more people think this is good idea, I could even again introduce
some compatibility code to cg-Xlib which will rewrite symlinkish HEAD
when it hits it (the kind of stuff we did in the old times).
> Sure, it can wait until git 1.0, but it would be great to keep this goal
> in mind.
>
> Disclaimer - I'm not reading the git mailing list, so if it was
> discussed, I'm sorry, I don't intend to restart that discussion - just
> give me the pointer and I'll read it.
I didn't notice such a discussion yet.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Do I misunderstand cg-merge --squash option
From: Alan Chandler @ 2005-11-10 20:36 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20051110192923.GT30496@pasky.or.cz>
On Thursday 10 Nov 2005 19:29, Petr Baudis wrote:
>
> Right now, what about trying to manually select the merge base?
>
> public$ cg-merge -b v1.0 master
Actually, that does merge very nicely. However, I don't think its what I
want. From gitk I get both routes back to my initial commit, both the fast
track one and the slow train via all stations en-route.
I have had more success with grafting (which you kindly informed me about
yesterday)
something like
echo `cg-object-id v1.0` `cg-object-id initial_commit` >.git/info/grafts
lf I make a branch out of the parent of v1.0 before doing this, I end up with
there being a side branch of the old history and my master branch headed back
through a quick route to the initial_commit.
Something strange (well actually not that unexpected, the more I think about
it) has happened though.
I was trying to see if cg-clone would effectively me make a new repository
without the grafts in it (ie with real commit object with a parent as
specified via the graft) but it doesn't - it just looses the graft and
rebrings all the old history back in
Is that a bug?
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: merge-one-file: use common as base, instead of emptiness.
From: Petr Baudis @ 2005-11-10 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6fgxn28.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 10, 2005 at 09:30:55PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > But obviously now the trouble is opposite, when the files are completely
> > unrelated, since now you likely get large conflicting areas interleaved
> > with some scarce common lines... And this might get to be a big PITA to
> > resolve as well.
>
> Yeah, you can always count lines in $orig and $src2 after
> two-file merge runs, and if it appears we do not have enough
> common section just empty the $orig before running merge.
Reasonable solution, I like that. Let's say 50%, like for the renames
detection?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-10 20:34 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, git
In-Reply-To: <20051109081906.GA4960@c165.ib.student.liu.se>
Dear diary, on Wed, Nov 09, 2005 at 09:19:06AM CET, I got a letter
where Fredrik Kuivinen <freku045@student.liu.se> said that...
> On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:
> > Fredrik Kuivinen <freku045@student.liu.se> writes:
> >
> > >> Oops, I missed that part. This is unsafe in theory, if you
> > >> could overwrite existing file3_master or file3_dev. Does that
> > >> matter in practice?
> > >
> > > It wont overwrite any existing files. If there is a file named
> > > 'file3_master' then the new file will be named 'file3_master_1' and if
> > > that file also exists the new file will be named 'file3_master_2', and
> > > so on.
> >
> > Another thing to watch out is that a branch name could have a
> > slash in it. It might make more sense to just name the heads file3~2
> > or file3~3 (with as many ~s repeated to avoid name clashes) like
> > Pasky does.
> >
>
> Oups, I haven't thought about that. I kind of like the idea that you
> can see the branch name in the file names though. How about replacing
> any slashes in the branch names with underscores? So the branch
> 'foo/bar' will give rise to files with suffixes like '_foo_bar' and
> '_foo_bar_<number>'.
I like it too. :-)
Now, this would look like file3~master in Cogito (or file3~~master in
case of name conflict, etc.).
Thanks for the idea,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Andreas Ericsson @ 2005-11-10 20:30 UTC (permalink / raw)
To: git
In-Reply-To: <20051110185423.GA7212@blackbean.org>
Jim Radford wrote:
> On Thu, Nov 10, 2005 at 12:14:29AM -0800, Junio C Hamano wrote:
>
>> I think archimport part needs to be split out just like its
>> svn/cvs cousins,
>
>
> I don't agree. The chance of running git-archimport and not having
> arch installed is significantly less likely than the chance of not
> noticing that the git-archimport program exists because it was moved
> into a separate package that you didn't know you needed to install in
> the first place.
>
How is this different for when svnimport and cvsimport was moved out? I
don't think anyone expected people to run those commands by accident
without noticing that they fail without the svn || cvs installed underneath.
> The main reason I see for splitting cvs and email import out is the
> non-standard dependencies, cvsps and perl(Email::Valid).
Define "non-standard". String::ShellQuote isn't installed by default on
Fedora Core 3 but is required by git-archimport.
> While for
> svn import it's to keep from requiring subversion-perl of everone who
> installs git-core. This dependency is added automatically, so you
> cannot easily just ignore it like you can in the arch/tla case.
>
It's fairly simple to provide a custom find-requires script.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: merge-one-file: use common as base, instead of emptiness.
From: Junio C Hamano @ 2005-11-10 20:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051110194317.GV30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> But obviously now the trouble is opposite, when the files are completely
> unrelated, since now you likely get large conflicting areas interleaved
> with some scarce common lines... And this might get to be a big PITA to
> resolve as well.
Yeah, you can always count lines in $orig and $src2 after
two-file merge runs, and if it appears we do not have enough
common section just empty the $orig before running merge.
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Pavel Roskin @ 2005-11-10 20:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051110192430.GS30496@pasky.or.cz>
Hi, Petr!
On Thu, 2005-11-10 at 20:24 +0100, Petr Baudis wrote:
> can you still remember why did you introduce this? In GNU cp
> documentation, I can see just
>
> -b, --backup
> Make backups of files that are about to be overwritten or removed.
>
> which doesn't make sense to me - -L dereferences symlinks.
You are right, it must be my error. Anyway, it was so long ago that I
would need to review and retest it.
While at that, let's stop using symlinks. git doesn't use symlinks on
Cygwin. I think git should use that code on all OSes, since the
benefits of using symlinks are minimal (I think the only benefits are
their atomicity and resolving the reference in the kernel rather than in
userspace). Having more uniform code for all platforms would simplify
development and testing. It could also reduce requirements for the
transport protocols. Finally, symlinks could be still used by the users
(if they know what they are doing) - git and cogito would simply become
symlink agnostic.
When files are copied around, symlinks are pain to deal with. They
require special handling to be preserved both for remote operation and
dereferenced for local operation (that's what my patch was intended to
do). I'm not even considering what would happen when cloning from Linux
to Windows or vice versa.
Sure, it can wait until git 1.0, but it would be great to keep this goal
in mind.
Disclaimer - I'm not reading the git mailing list, so if it was
discussed, I'm sorry, I don't intend to restart that discussion - just
give me the pointer and I'll read it.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-10 20:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Fredrik Kuivinen, Junio C Hamano, Jon Loeliger, git
In-Reply-To: <46a038f90511101154p4ef99cddv82d56272921a80ac@mail.gmail.com>
Dear diary, on Thu, Nov 10, 2005 at 08:54:43PM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 11/11/05, Petr Baudis <pasky@suse.cz> wrote:
> > Well, basically like right now ;-).
>
> Exactly. Which isn't documented, and has several subtleties that I
> don't know of.
Yes - from the user standpoint it is supposed to be a foolproof (for a
reasonable value of 'fool') and should always guide you around. From a
developer's standpoint it might not be entirely crystal-clear, though.
;-)
> There are some semantics to exchange info between cg-merge and
> cg-commit and for handling the index while the user is resolving
> conflicts or reviewing the merge before committing. I'm not familiar
> with them, and I'm unsure what the design is...
The design is "keep arbitrary bunch of files in .git recording our state
wrt. merging". I want to tidy that up and keep all that in
.git/cg-merge-state/ or something.
> - how do cg-merge and cg-commit pass around the parents, commit msg,
> files being merged vs dirty files on tree, etc? (easy: those lowercase
> temp files in .git)
Yes, lowercase temp files. Well, the commit msg itself is composed only
in cg-commit.
> - how do you run cg-status/cg-diff without messing up the index? does
> running cg-status or cg-diff stand any risk of accidentally marking
> for inclusion dirty files that are not part of the merge? hopefully
> not, and then what's the technique?
cg-status and cg-diff are safe anytime, being basically read-only
commands wrt. the interesting index information.
Well, they _do_ touch your index (but only modifying the stat
information), and that may get you into some trouble, but only in case
of some seemingly quite rare permission problem, I think (and that will
trash your index anytime, not just during a merge). There was a thread
about that about a month or two ago, IIRC.
> - should cg-status show more about the status of the index ?
In what sense? It shows if merge is in progress. It doesn't show
conflicts, but that's because...
> - how does cg-commit know whether conflicts have been resolved at
> all? (perhaps it doesn't even try!)
...we don't actually track them yet. That's considered a bug, I want to
fix it, and it even has some non-zero priority.
> - how do you reset the 'we are merging' status?
cg-reset (except when you were merging over a dirty state; hmm, we don't
have a direct command for cancelling that, it seems).
cg-merge will now hint you about cg-reset.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Junio C Hamano @ 2005-11-10 19:55 UTC (permalink / raw)
To: Yaacov Akiba Slama; +Cc: git
In-Reply-To: <437318CD.2050401@slamail.org>
Yaacov Akiba Slama <ya@slamail.org> writes:
> /trunk/path/to/file
> /trunk/new/path/to/file (this is a copy of /branches/branch_1/path/to/file)
> /branches/branch_1/path/to/file
> /branches/branch_n/path/to/file
> /tags/tag_1/path/to/file
> /tags/tag_m/path/to/file
>
> Now the commit 109fc2b97b73090a4a0a6550cdf9b2446fd12389 creates a new
> commit with two parents:
> 1) HEAD
> 2) the git branch called "branch_1"
>
> From what I read about the definition of commit in git's documentation,
> that seems to be ok, but can this marking of "branch_1" as a parent of
> this commit be dangerous for merges done later in pure git ?
I think it is reasonable to record both as parents, to make the
development history in branch_1 accessible from the trunk branch
after they are merged, and I do not think it is dangerous at
all. It is just a regular merge which, when viewed from trunk
side of the history, creates a directory called 'new' at the top
level, and adds bunch of files there, and if you are viewing it
with rename/copy detection you may even notice that those
changes are mostly copy edits.
But the above example brings up an interesting question.
Subversion lets you copy freely and does not require the
developer to express machine-readably what that copy is about.
Also it lets copy partial trees. So it is entirely plausible to
run your project like this:
1. Repo has /trunk/i386/blah.c; i.e. 'ls' at the
toplevel of the working tree shows 'i386' directory.
/trunk/i386/blah.h
2. Somebody wants to do x86-64 equivalent of existing
thing, and starts preparing it by copying existing
i386 thing, into his branch, and do development
there.
/trunk/i386/blah.c
/branches/wip-x86-64/blah.c (copy from /trunk/i386)
3. Later, that x86-64 equivalent matures, and gets
merged into trunk:
/trunk/i386/blah.c
/trunk/x86-64/blah.c (merge back from /branches/wip-x86-64)
/branches/wip-x86-64/blah.c (development ceased)
But it is also plausible to do this instead:
2'. Instead of the above, you copy the whole thing
/trunk/i386/blah.c
/branches/wip/i386/blah.c (copy from /trunk)
/branches/wip/x86-64/blah.c (then copy from /branches/wip/i386)
3'. Instead of the above:
/trunk/i386/blah.c (merge back from /branches/wip)
/trunk/x86-64/blah.c (merge back from /branches/wip)
/branches/wip/i386/blah.c (development ceased)
/branches/wip/x86-64/blah.c (development ceased)
Do you need to handle the history resulting from these cases
differently when importing from subversion? I have a feeling
that the user needs to tell what really happend for you to
handle this sensibly (tree root level is different), but I am
not offhand sure what the issues are.
^ permalink raw reply
* [PATCH] Fix confusing git-update-ref error message
From: Petr Baudis @ 2005-11-10 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When git-update-ref has hit the "Ref %s changed to %s" error, I just stare
at it, left puzzled. This patch attempts to reword that to a more useful
and less confusing error message.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
update-ref.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/update-ref.c b/update-ref.c
index 65dc3d6..d79dc52 100644
--- a/update-ref.c
+++ b/update-ref.c
@@ -42,7 +42,7 @@ int main(int argc, char **argv)
if (oldval) {
if (memcmp(currsha1, oldsha1, 20))
- die("Ref %s changed to %s", refname, sha1_to_hex(currsha1));
+ die("Ref %s is at %s but expected %s", refname, sha1_to_hex(currsha1), sha1_to_hex(oldsha1));
/* Nothing to do? */
if (!memcmp(oldsha1, sha1, 20))
exit(0);
^ permalink raw reply related
* Re: Expected Behavior?
From: Martin Langhoff @ 2005-11-10 19:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: Fredrik Kuivinen, Junio C Hamano, Jon Loeliger, git
In-Reply-To: <20051110193430.GU30496@pasky.or.cz>
On 11/11/05, Petr Baudis <pasky@suse.cz> wrote:
> Well, basically like right now ;-).
Exactly. Which isn't documented, and has several subtleties that I
don't know of.
> Merging is a two-stage process, where the two stages are isolated and
> the latter does not interfere with the former. The former one is doing
> the actual content merge, and that's what cg-merge does. The latter one
> is recording the merge in history, and that's what cg-commit does.
There are some semantics to exchange info between cg-merge and
cg-commit and for handling the index while the user is resolving
conflicts or reviewing the merge before committing. I'm not familiar
with them, and I'm unsure what the design is...
- how do cg-merge and cg-commit pass around the parents, commit msg,
files being merged vs dirty files on tree, etc? (easy: those lowercase
temp files in .git)
- how do you run cg-status/cg-diff without messing up the index? does
running cg-status or cg-diff stand any risk of accidentally marking
for inclusion dirty files that are not part of the merge? hopefully
not, and then what's the technique?
- should cg-status show more about the status of the index ?
- how does cg-commit know whether conflicts have been resolved at
all? (perhaps it doesn't even try!)
- how do you reset the 'we are merging' status?
Anyway, that's off the top of my head, and probably shows you that I'm
not 200% familiar with all the tricks available for handling the
index.
cheers,
martin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Linus Torvalds @ 2005-11-10 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0511101128510.4627@g5.osdl.org>
On Thu, 10 Nov 2005, Linus Torvalds wrote:
>
> But the point is, that if you actually run fsck every time you want to
> visualize your pending commits, you're going to feel the pain.
^^^^^^^
That should be "dangling", of course.
Linus
^ permalink raw reply
* Re: merge-one-file: use common as base, instead of emptiness.
From: Petr Baudis @ 2005-11-10 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7v64r16ro9.fsf_-_@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 10, 2005 at 05:41:10AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > I think having
> >
> > <<<<<
> > file1
> > =====
> > file2
> > >>>>>
> >
> > is an awful PITA to resolve, especially when the files actually are
> > similar. Running some vimdiff (or just diff and possibly applying either
> > way) on two separate files is much more convenient.
>
> You are right.
>
> How about something like this? This adds a specialized hackery
> flag, --no-add, to git-apply, and uses it to compute common base
> to be used for 2-file merge, instead of using /dev/null.
Wow, astonishingly simple.
> -- >8 -- cut here -- >8 --
> Unlike the previous round that merged the path added differently
> in each branches using emptiness as the base, compute a common
> version and use it as input to 'merge' program.
>
> This would show the resulting (still conflicting) file left in
> the working tree as:
>
> common file contents...
> <<<<<< FILENAME
> version from our branch...
> ======
> version from their branch...
> >>>>>> .merge_file_XXXXXX
> more common file contents...
>
> when both sides added similar contents.
But obviously now the trouble is opposite, when the files are completely
unrelated, since now you likely get large conflicting areas interleaved
with some scarce common lines... And this might get to be a big PITA to
resolve as well.
That said, I still really like --no-add and it would be heart-wrenching
to just coldly dismiss it. It is a great tool, but I would let the user
to use it manually. Possibly something like
git-twofile-merge foo~1 foo~2
(the name is stupid, obviously) or a button in some GUI tool.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] C implementation of the 'git' program.
From: Linus Torvalds @ 2005-11-10 19:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <20051110182631.3C5615BF90@nox.op5.se>
On Thu, 10 Nov 2005, Andreas Ericsson wrote:
>
> This patch provides a C implementation of the 'git' program and introduces
> support for putting the git-* commands in their own directory. It also
> saves some time on executing git-* commands in a tight loop and it prints
> the currently available git commands in a nicely formatted list.
I think this makes sense - "git" may be a very simple program even in
shell, but hey, it's simple even in C, and while performance may be a
secondary issue, when it is in C we will have the option to extend in more
effectively later.
For example, we might implement some things directly in the "git" wrapper.
And the performance difference does seem to be quite noticeable too..
> The location of the GIT_LIB can be obtained by running
>
> git --lib
I think this might be a bit ambiguous. When I see "GIT_LIB", to me it
implies traditional libraries (ie a "libgit.a" kind of thing), not the
kind of "git executable plugin" directory.
So I'd suggest renaming "--lib" and "GIT_LIB" to be more of a "--libexec"
kind of flavor, if only to avoid that confusion. Even if the actual
directory ends up being /usr/lib/git-<version>/ as in my original
suggestion, I think it's good to make it clear that it's not just some
kind of "link type" library, but more of a combination of libraries and
plugins and executables.
But maybe that's just me?
Linus
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-10 19:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Fredrik Kuivinen, Junio C Hamano, Jon Loeliger, git
In-Reply-To: <46a038f90511091847t70567e50o2303f1dc7ada2464@mail.gmail.com>
Dear diary, on Thu, Nov 10, 2005 at 03:47:38AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> > Yes. My longer plan is to use the strategy resolvers as well, but my
> > TODO list is big... And I don't perceive this as a critical thing (the
> > standard strategy seems to work well enough), although I would like to
> > see this before 1.0.
>
> Fair enough. If you can outline how the interaction between cg-merge
> and cg-commit are expected to work, I'll try and find some time for
> that.
Well, basically like right now ;-).
Merging is a two-stage process, where the two stages are isolated and
the latter does not interfere with the former. The former one is doing
the actual content merge, and that's what cg-merge does. The latter one
is recording the merge in history, and that's what cg-commit does.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Linus Torvalds @ 2005-11-10 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git, linux-kernel
In-Reply-To: <7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net>
On Thu, 10 Nov 2005, Junio C Hamano wrote:
>
> Yeah, the original proposal (in TODO list) explicitly stated why
> I chose lost-found instead of lost+found back then, and somebody
> on the list (could have been Pasky but I may be mistaken) said
> not to worry. In any case, if we go the route Daniel suggests,
> we would not be storing anything on the filesystem ourselves so
> this would be a non-issue.
I don't know how many people do this, but with the current kernel sources,
"git-fsck-cache --full" takes about a minute on a reasonable fast machine
with everything in cache (ie no real disk activity to speak of)
I personally think that's fine, since I repack my trees every once in a
while, and almost never run a "--full" check, I only do incrementals
(which are basically free). And I suspect that I run fsck a lot more than
anybody else does.
But the point is, that if you actually run fsck every time you want to
visualize your pending commits, you're going to feel the pain.
I think having some kind of lost+found so that you don't have to re-run
fsck just because you decided to look at them some other way (use "git
log" instead of "gitk" or whatever) makes a lot of sense. But yes, it
shouldn't really be called "lost+found" due to some rather serious
confusion that can cause.
Linus
^ permalink raw reply
* Re: Do I misunderstand cg-merge --squash option
From: Petr Baudis @ 2005-11-10 19:29 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511101915.53736.alan@chandlerfamily.org.uk>
Dear diary, on Thu, Nov 10, 2005 at 08:15:53PM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> said that...
> On Thursday 10 Nov 2005 10:12, Petr Baudis wrote:
> > Why do you want to do a squash merge?
>
> I used git experimentally as I built a web application from scratch, learning
> both what I wanted the application to look like and how to do it with the
> packages I was using. There is several hundreds of commits that are totally
> irrelevant (both because they were all different directions I was trying and
> then backing out of and because I saved state just were I was when I gave up
> for the day).
>
> So what I was experimenting with was whether I could somehow get rid of that
> history (at least in one branch) before making that history public.
Aha. That sounds reasonable.
> > I told you in the documentation - "re-merging with that branch later
> > will cause trouble". If you want to be able to re-merge the branch
> > later, you shouldn't use squash merge. And you shouldn't use squash
> > merge anyway, expect for few narrow use cases.
>
> I know - I saw the warning - and I was only experimenting. I just didn't
> understand what had happened.
If you would be doing something like this again, it's best to merge, and
then rather than continuing to develop what you merged, just throw that
branch again and re-clone the merged repository.
Right now, what about trying to manually select the merge base?
public$ cg-merge -b v1.0 master
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Petr Baudis @ 2005-11-10 19:24 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1124832796.23795.9.camel@dv>
Hello,
Dear diary, on Tue, Aug 23, 2005 at 11:33:16PM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> Local URL handling needs to be fixed to handle .git/HEAD properly, since
> it's a symlink in the upstream directory. A new flag "-b" for fetch_*
> functions is introduced, meaning "dereference" (like in GNU cp).
>
> @@ -205,6 +209,11 @@ fetch_local()
> [ "$1" = "-s" ] && shift
>
> cp_flags_l="-vdpR"
> + if [ "$1" = "-b" ]; then
> + cp_flags_l="-vb" # Dereference symlinks
> + shift
> + fi
> +
> if [ "$1" = "-u" ]; then
> cp_flags_l="$cp_flags_l -fu$can_hardlink"
> suggest_hardlink=
can you still remember why did you introduce this? In GNU cp
documentation, I can see just
-b, --backup
Make backups of files that are about to be overwritten or removed.
which doesn't make sense to me - -L dereferences symlinks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Do I misunderstand cg-merge --squash option
From: Alan Chandler @ 2005-11-10 19:15 UTC (permalink / raw)
To: git
In-Reply-To: <20051110101206.GP30496@pasky.or.cz>
On Thursday 10 Nov 2005 10:12, Petr Baudis wrote:
>
> Why do you want to do a squash merge?
>
I used git experimentally as I built a web application from scratch, learning
both what I wanted the application to look like and how to do it with the
packages I was using. There is several hundreds of commits that are totally
irrelevant (both because they were all different directions I was trying and
then backing out of and because I saved state just were I was when I gave up
for the day).
So what I was experimenting with was whether I could somehow get rid of that
history (at least in one branch) before making that history public.
>
> I told you in the documentation - "re-merging with that branch later
> will cause trouble". If you want to be able to re-merge the branch
> later, you shouldn't use squash merge. And you shouldn't use squash
> merge anyway, expect for few narrow use cases.
I know - I saw the warning - and I was only experimenting. I just didn't
understand what had happened.
I am now experimenting with another approach using grafts etc. But I will
post on that seperately, so as not to confuse titles of the e-mail thread.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Daniel Barkalow @ 2005-11-10 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6fgz5nc.fsf@assigned-by-dhcp.cox.net>
On Thu, 10 Nov 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > ... (That is, you
> > want the head of an unreachable chain listed for recovery, but not other
> > things reachable from it; you also may want the list of blobs and trees
> > not reachable either from a ref or from something listed for recovery, but
> > not omitting a blob reachable only from an unreachable tree)
>
> I thought that was what those 'dangling blah' was about...
> That is, if you make commit A and then on top of that commit B,
> and lose both, you will see dnagling for B but not A (which is
> reachable from B).
Right; what I was pointing out is that you want the dangling commits, but
the unreachable blobs and trees, and want reachability to count things
listed as dangling, which is a somewhat novel combination of desires, I
think.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Junio C Hamano @ 2005-11-10 19:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511101317500.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> ... (That is, you
> want the head of an unreachable chain listed for recovery, but not other
> things reachable from it; you also may want the list of blobs and trees
> not reachable either from a ref or from something listed for recovery, but
> not omitting a blob reachable only from an unreachable tree)
I thought that was what those 'dangling blah' was about...
That is, if you make commit A and then on top of that commit B,
and lose both, you will see dnagling for B but not A (which is
reachable from B).
^ permalink raw reply
* [PATCH] Add missing git-core and cvsps RPM dependencies
From: Jim Radford @ 2005-11-10 19:03 UTC (permalink / raw)
To: git
Add missing git-core and cvsps RPM dependencies.
Signed-off-by: Jim Radford <radford@blackbean.org>
diff --git a/git-core.spec.in b/git-core.spec.in
index 26846d0..ce9acd8 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -22,20 +22,21 @@ elsewhere for tools for ordinary humans
%package svn
Summary: Git tools for importing Subversion repositories.
Group: Development/Tools
-Requires: subversion
+Requires: git-core, subversion
%description svn
Git tools for importing Subversion repositories.
%package cvs
Summary: Git tools for importing CVS repositories.
Group: Development/Tools
-Requires: cvs
+Requires: git-core, cvs, cvsps
%description cvs
Git tools for importing CVS repositories.
%package email
Summary: Git tools for sending email.
Group: Development/Tools
+Requires: git-core
%description email
Git tools for sending email.
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 0.99.9g
From: Jim Radford @ 2005-11-10 18:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net>
On Thu, Nov 10, 2005 at 12:14:29AM -0800, Junio C Hamano wrote:
> I think archimport part needs to be split out just like its
> svn/cvs cousins,
I don't agree. The chance of running git-archimport and not having
arch installed is significantly less likely than the chance of not
noticing that the git-archimport program exists because it was moved
into a separate package that you didn't know you needed to install in
the first place.
The main reason I see for splitting cvs and email import out is the
non-standard dependencies, cvsps and perl(Email::Valid). While for
svn import it's to keep from requiring subversion-perl of everone who
installs git-core. This dependency is added automatically, so you
cannot easily just ignore it like you can in the arch/tla case.
> and perhaps documentation into another separate package.
There is no need for a separate documentation RPM, since the
documentation is marked as such and rpm has a standard way to avoid
installing them (--excludedocs).
-Jim
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Andreas Ericsson @ 2005-11-10 18:34 UTC (permalink / raw)
To: git
In-Reply-To: <43737F9E.60703@zytor.com>
H. Peter Anvin wrote:
> Jeff Garzik wrote:
>
>>
>>> Oh, and we will not be moving things out of /usr/bin/ during 1.0
>>> timeframe.
>>
>>
>>
>> :( bummer. I do like the elegance of having /usr/bin/git executing
>> stuff out of /usr/libexec/git.
>>
>> /usr/libexec/git also makes it IMO cleaner when integrating git
>> plugins from third parties (rpm -Uvh git-newfeature), because you
>> don't have to worry about the /usr/bin namespace.
>>
>
> It's nice in concept, but I think there are a lot of reasons why this is
> a bad idea:
>
> - "man" doesn't handle it. It would be another thing if "man" could be
> taught to understand commands like "man cvs checkout" or "man git fetch".
>
This is moot. man-pages can still be named git-fetch.
> - There is no general way to teach shells etc about it, for tab
> completion etc.
>
Add the lib directory to the path (for git-<tab><tab>) or have it
auto-evaluate the result of a git command-listing.
> - Makes it harder (but not impossible) to run git from a build directory
> without installing it first.
>
Provided adding --lib=. is considered difficult, yes. Btw, this problem
still applies as some of the programs run other programs that are
expected to be in the path.
I've just posted a patch (used my submit-patch script, which was stupid
since I should have posted it here) that doesn't have any of these problems.
> In comparison, the issue of clutter in /usr/bin is actually a pretty
> small issue, especially with htree. Most vendors have gone back to
> putting everything into /usr/bin since all variants that involve
> splitting it up seem to be more of a loss than a gain.
>
Fair enough. With the patch I've just sent (C implementation of the
'git' program) this option is certainly available.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Daniel Barkalow @ 2005-11-10 18:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, H. Peter Anvin, git, linux-kernel
In-Reply-To: <20051110180311.GR30496@pasky.or.cz>
On Thu, 10 Nov 2005, Petr Baudis wrote:
> Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> > "H. Peter Anvin" <hpa@zytor.com> writes:
> >
> > > May I *STRONGLY* urge you to name that something different.
> > > "lost+found" is a name with special properties in Unix; for example,
> > > many backup solutions will ignore a directory with that name.
> >
> > Yeah, the original proposal (in TODO list) explicitly stated why
> > I chose lost-found instead of lost+found back then, and somebody
> > on the list (could have been Pasky but I may be mistaken) said
> > not to worry.
>
> It was the Large Angry SCM. I share your concern.
>
> > In any case, if we go the route Daniel suggests, we would not be
> > storing anything on the filesystem ourselves so this would be a
> > non-issue.
>
> I like Daniel's route as well, for the separate command. But it would be
> nice to also have a way to tell git-fsck-cache to save the lost+found
> refs as it goes, much like the filesystem fsck. So if it reports some
> unreachable refs, you will not need to tell it to do the same job
> _another_ time to find out the refs and pass them to gitk. Then again,
> if we do this, the utility of a separate command will be questionable.
Maybe git-fsck-objects should have an option to make it note dangling
objects of certain types, and then count these as reachable? (That is, you
want the head of an unreachable chain listed for recovery, but not other
things reachable from it; you also may want the list of blobs and trees
not reachable either from a ref or from something listed for recovery, but
not omitting a blob reachable only from an unreachable tree)
-Daniel
*This .sig left intentionally blank*
^ 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