* Re: [PATCH] Bugfix: stop if directory already exists
From: Andreas Ericsson @ 2005-11-14 10:47 UTC (permalink / raw)
To: git
In-Reply-To: <200511141136.19192.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> On Monday 14 November 2005 10:28, Andreas Ericsson wrote:
>
>>But we name them differently, as hpa pointed out some week ago.
>>
>>When I see "usage: <prog> <command>" I expect to find the info in "man
>><prog>". Soon, this will work to get the right page
>>
>> git --help <command>
>
>
> This is a nice feature, but still needs educating the user.
This feature goes away with the huge man-page.
> I think that the idea of a huge git man page is not that bad; for sure,
> it can be created automatically.
>
> A huge man page helps searching a command name (Ah, what was the
> command to see commit logs per file? What is the counterpart of
> "cvs update" called?).
>
This is already implemented (sort of), but perhaps have both? Or
pointers to the other man-pages from the "git" one (as is already sort
of done).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Bugfix: stop if directory already exists
From: Josef Weidendorfer @ 2005-11-14 10:36 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <437858A1.9010007@op5.se>
On Monday 14 November 2005 10:28, Andreas Ericsson wrote:
> But we name them differently, as hpa pointed out some week ago.
>
> When I see "usage: <prog> <command>" I expect to find the info in "man
> <prog>". Soon, this will work to get the right page
>
> git --help <command>
This is a nice feature, but still needs educating the user.
I think that the idea of a huge git man page is not that bad; for sure,
it can be created automatically.
A huge man page helps searching a command name (Ah, what was the
command to see commit logs per file? What is the counterpart of
"cvs update" called?).
Josef
^ permalink raw reply
* Re: Balanced packing strategy
From: Josef Weidendorfer @ 2005-11-14 10:24 UTC (permalink / raw)
To: git; +Cc: Craig Schlenter, Petr Baudis
In-Reply-To: <W4340426396265721131944586@webmail12>
On Monday 14 November 2005 06:03, Craig Schlenter wrote:
> Hi
>
> > From: Josef Weidendorfer [mailto:Josef.Weidendorfer@gmx.de]
> > [snip]
> > AFAICS, the git native protocol (which is nothing more than a pack itself
> > for each transfer) even has this problem, too: If you are updating every
> > day via git native, the sum of transfered bytes in a month will be a
> > multiple of one git transfer for all the month's changes.
>
> Interesting ... is this because in a bigger pack the compression will
> be better as there is probably more stuff to "delta" against?
No, it is because of the self-containment of git packs: Deltas (storing
differences instead of full file content) are only allowed to other
objects in the same pack. The self-containment is a safety measure: you
do not want to have dependencies to the outside, because this would
destroy the contents of a pack by changing/removing another file.
So if the changes of a day are 100 oneliners to different files, the pack
has to contain the full content of the 100 files. With incremental
packing, you would probably add only the 100 oneliners (ie. deltas) at end
of the pack, because the full file contents have to be in the pack if there
was a change to them recorded in the pack previously. And this probability
is higher if the pack contains a larger history of the project.
Back to the example: By doing a git transfer every day, you always will
transfer the full contents of files which where changed on this day, because
git protocol transfers self-contained packs.
Josef
^ permalink raw reply
* Question on GIT tutorial.
From: Franck @ 2005-11-14 10:20 UTC (permalink / raw)
To: Git Mailing List
Hi,
I have a question about the GIT tutorial. At page 21, there is a
description of "subsystem maintainer" work cycle, I don't understand
why point 3 is needed. This point tells:
"""
Copy over the packed files from "project lead" public repository to
your public repository.
"""
Why is it needed ?
Thanks
--
Franck
^ permalink raw reply
* Re: [PATCH] Bugfix: stop if directory already exists
From: Andreas Ericsson @ 2005-11-14 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <200511141029.18256.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> So just another suggestion: Why not put most of the
> documentation in a huge "git" man page?
Becuase it's horrible. I like the fact that they are split up.
> cvs does this (3601 lines
> here), all the shells have huge man pages (bash: 4794).
> We would be in a good tradition ;-)
>
We would be in tradition, but not necessarily a good one. Just because
some stupid swede let some herrings ferment in a tin can some 800 years
ago there's really no need to say "surströmming! What a clever idea!!"
and actually eat the horrible things.
--
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: Petr Baudis @ 2005-11-14 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vwtjb3c4i.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Nov 14, 2005 at 08:46:37AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> BTW, does anybody actually use these commit walkers over SSH?
> Cogito switched out of it before 0.16r1 if I understand
> correctly, and git barebone never used it. It might not be a
> bad idea to deprecate these altogether, now packed transfer
> seems to be much nicer.
Yes, Cogito switched out of it before 0.16rc1, but there is still plenty
of users of older Cogito versions. Well, when 0.16 is out, those should
upgrade anyway, so this could be a nice gentle kick... ;-)
--
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] Bugfix: stop if directory already exists
From: Josef Weidendorfer @ 2005-11-14 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsp3zjwm.fsf@assigned-by-dhcp.cox.net>
On Monday 14 November 2005 09:57, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> > usage: git clone ...
> > For more details, see 'man git-clone'
>
> doing too much awk these days"). And "for more details see man"
> goes without saying.
Of course; it was more about the current inconsistency: usage
says "git clone", but for the man page, you have to know that
there is an additional command "git-clone" with extra man page.
Usually, if I see e.g. "usage: cvs diff", I look up the man
page of "cvs" searching for "diff" on it, not "cvs-diff".
So just another suggestion: Why not put most of the
documentation in a huge "git" man page? cvs does this (3601 lines
here), all the shells have huge man pages (bash: 4794).
We would be in a good tradition ;-)
Josef
^ permalink raw reply
* Re: [PATCH] Bugfix: stop if directory already exists
From: Andreas Ericsson @ 2005-11-14 9:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git
In-Reply-To: <7vpsp3zjwm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
>> usage: git clone ...
>> For more details, see 'man git-clone'
>
>
> And "for more details see man" goes without saying.
>
But we name them differently, as hpa pointed out some week ago.
When I see "usage: <prog> <command>" I expect to find the info in "man
<prog>". Soon, this will work to get the right page
git --help <command>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Junio C Hamano @ 2005-11-14 9:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Petr Baudis, git
In-Reply-To: <46a038f90511140051o1fa5ef7cyb9dd723fb8161ef9@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> I'm curious. What would be the advantages of this over git-read-tree
> -m for use within a single repo?
On a large tree I had an impression that applying patch and then
falling back on 3-way is faster, but other than that, nothing,
really. Just being able to use a single mechanism, which does
not buy us much.
> OTOH, if this is heading towards teaching git-am how to apply changes
> to binary files based on known SHA1s, this will give birth to a type
> of patch that applies only if you have the objects beforehand. Is that
> enough to get by? Perhaps we need a format to fully describe binary
> files?
I'd rather not see our "patch" go in the direction of recording
both pre- and post-image of blob for binary files, which is what
we would end up doing if we really want to do binary flexibly.
Well, that may be nice as an option, but not by default.
An option halfway in between would be to record the pre-image
SHA1 and post- blob, perhaps compressed-uuencoded. This would
limit us to the case that the recipient has not touched the
binary file and replacing it, but in practice that might be
enough.
I'm willing to do the C hackery myself if there is enough
interest in it.
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Petr Baudis @ 2005-11-14 9:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90511140051o1fa5ef7cyb9dd723fb8161ef9@mail.gmail.com>
Dear diary, on Mon, Nov 14, 2005 at 09:51:29AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> In the meantime, the user experience of working with a small team and
> a shared repo has improved significantly by switching from cg-update
> to cg-fetch && git-rebase origin. So much so that I suspect that it'd
> be a big win for cg-update to default to rebase on merges from
> 'origin'.
I still don't understand what's the point. And it is confusing for
the user, since the history suddenly doesn't reflect how the GIT
development happened (which is what the history is about), and it is
downright deadly as soon as more than one branch gets around, which
makes it even more confusing for the user (you can do cg-update, yeah
- oh wait, unless you do X, then you need to remember to always do
cg-update -R or whatever).
All the woes just to get rid of the merge commits. What's wrong on merge
commits? If they irritate you so much, cg-log -M. ;-)
--
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-14 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtjb3c4i.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>>Also places we execute git-upload-pack and git-receive-pack over
>>>an SSH connection need to be updated to execute 'git' with the
>>>first parameter 'upload-pack' and 'receive-pack' to make sure it
>>>would keep working with older or newer git on the other end.
>>
>>I've cooked up a patch that takes care of this if;
>> git daemon
>>is executed (rather than git-daemon)...
>
>
> Actually I was more worried about these git native protocols
> going over ssh, which is not helped by git-daemon. I think
> teaching the libdir to git-shell would make sense for "git
> restricted shell" users, but most users coming from ssh to run
> git native protocols would need to have some way of running the
> executable on the other end.
>
> My current thinking about this problem is that the handful
> programs that need to run "on the other end" should stay in
> /usr/bin, even after we move most things out of /usr/bin, if
> only to avoid configuration hassles. They are:
>
> receive-pack, upload-pack
> ssh-fetch, ssh-pull, ssh-push, ssh-upload
>
I liked your suggestion of deprecating the /usr/bin use a month or two
before it's effected better. We could then provide symlinks for the
necessary programs that point to their real locations in GIT_EXEC_PATH
and (someday) drop those links when they're no longer needed.
>
> Somehow libdir reminds me of where libraries are installed by
> the Makefile, which usually does not mean executables, and that
> was the reason I mentioned --exec-path. Although I do not have
> strong preference myself either way, I do not think the list
> cares too much either, so in order not to waste time by
> indecision, let's just say we use this one:
>
>
>>The form will be
>> exec_path=$(prefix)/lib/git-@@VERSION@@
>> GIT_EXEC_PATH
>> --exec-path
>>
>>for Makefile, environment and 'git', respectively. Substitute the
>>obvious part with whatever you prefer.
>
>
>>..., although I'm implementing Linus' idea of prepending the
>>GIT_EXEC_PATH to $PATH so the porcelainish scripts in git-core
>>shouldn't have to do it.
>
>
> This sounds good to me; let's go with it. Thanks.
>
I'll get busy then.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Bugfix: stop if directory already exists
From: Junio C Hamano @ 2005-11-14 8:57 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511131503.32078.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> Fix a typo: We do not want to run the directory as command,
> and want to terminate if the directory exists
> Additionally, update the usage message
Thanks.
> Should we use "git clone" or "git-clone" in the usage message?
I think "git clone" is probably preferred, given that we would
eventually want to be able to install them outside /usr/bin/,
leaving "git" wrapper (and very small number of other programs)
in /usr/bin/.
> usage: git clone ...
> For more details, see 'man git-clone'
My understanding of UNIX tradition of "usage:" is to be short
and sweet, to primarily help people who already know the command
but sometimes cannot remember how exactly the options are
spelled (e.g. "was that -F to specify the inter-field separator
to "sort" command? Ah, no, it wants -t -- silly me must be
doing too much awk these days"). And "for more details see man"
goes without saying.
^ permalink raw reply
* Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Andreas Ericsson @ 2005-11-14 8:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr79j1wfl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>git-email; This one only uses Email::Valid->address(), so I'll import
>>that function from the perl module so this dependency can be dropped and
>>git-send-email can be in the 'git' package.
>
>
> Hmph. This should have occurred to somebody when we did the same
> with subprocess.py, but obviously it went unnoticed.
>
Apparently it's not so easy. The Email::Valid thing contains a regex
some 5000 chars long. I personally think it's a fair bit overkill for
the purpose of send-email so we could well do with a much simpler
verification.
>
>>Programs introducing obscene or plain weird dependencies (cvsimport,
>>svnimport) can be put into their own package, but we should really try
>>to keep those extra packages to a minimum and simply force users who
>>want all the fluffy niceties of the 'git' package to install whatever's
>>required (or install with --nodeps, or from source, or...).
>
>
> I am not so sure about that. Why should the number of packages
> matter?
Because it's a nuisance to keep track of them.
> We could argue that the current splitting of RPM
> packages is half-done in that sense --- we lack the "tying
> together" package which itself is empty but depends on
> subpackages that implements common client-side. Call that
> git-scm (or "git") and have the end users install it, then it
> would pull what it depends on along with it. No?
>
Isn't this exactly what I suggested (apart from git-scm)? client-side
stuff goes in "git", basic functionality (server side stuff) in git-core
and git-* for special functionality introducing odd dependencies (cvs,
svn, http).
Since all packages would require git-core we can tack everything that
doesn't require anything special in there and server-side installs will
be smooth as you please.
This change should be done before 1.0 though, since people will probably
expect some sort of package naming stability later.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Martin Langhoff @ 2005-11-14 8:51 UTC (permalink / raw)
To: Junio C Hamano, Petr Baudis; +Cc: git
In-Reply-To: <7vwtjb4vc4.fsf@assigned-by-dhcp.cox.net>
On 11/14/05, Junio C Hamano <junkio@cox.net> wrote:
> It shouldn't be too tricky to enhance "git am" (git-apply called
> at around line 49 in it) to grok binary differences for this
> purpose, because you would have both pre- and post-image blob in
> your object database, because the patch is being used only to
> replay what you have in your reository, and it records their
> abbreviated SHA1 name.
I'm curious. What would be the advantages of this over git-read-tree
-m for use within a single repo? I keep thinking that I need an
intra-repo way of doing it (arguably faster and more reliable),
instead of git-format-patch|git-am, which is less reliable and slower.
OTOH, if this is heading towards teaching git-am how to apply changes
to binary files based on known SHA1s, this will give birth to a type
of patch that applies only if you have the objects beforehand. Is that
enough to get by? Perhaps we need a format to fully describe binary
files?
> I've never felt need to "merge" the binary files myself and had
> never got around doing this, but if you are interested, it would
> go something like this:
That's quite a bit of C hacking... I'm game for all the Perl and shell
scripts in git, but I know better than start learning C in _this_
project with you, Linus and the whole list watching me make the fool
;-)
So noone hacks this bit of C you are proposing I'll eventually get
something done with cg-update and git-rebase.
In the meantime, the user experience of working with a small team and
a shared repo has improved significantly by switching from cg-update
to cg-fetch && git-rebase origin. So much so that I suspect that it'd
be a big win for cg-update to default to rebase on merges from
'origin'.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Junio C Hamano @ 2005-11-14 8:10 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437788A0.6030103@op5.se>
> Linus Torvalds wrote:
>> Quite frankly, I'd really prefer to see the git-core-http as a
>> separate package.
>>
>> I think it's ludicrous that people want to split out gitk (because
>> it wants tcl/tk), but that we then add all of these really obscure
>> dependencies for the http part.
One thing we could do is to push http-push out of the common
package and keep http-fetch. I personally feel that the http
commit walker is as much core as gitk is. If you are git://
capable that is great, and if you are git+ssh:// capable that
may be even nicer because you could push. But let's face it:
there are always more pullers than pushers, and everybody can
talk http over his firewall.
Andreas Ericsson <ae@op5.se> writes:
> git-email; This one only uses Email::Valid->address(), so I'll import
> that function from the perl module so this dependency can be dropped and
> git-send-email can be in the 'git' package.
Hmph. This should have occurred to somebody when we did the same
with subprocess.py, but obviously it went unnoticed.
> Programs introducing obscene or plain weird dependencies (cvsimport,
> svnimport) can be put into their own package, but we should really try
> to keep those extra packages to a minimum and simply force users who
> want all the fluffy niceties of the 'git' package to install whatever's
> required (or install with --nodeps, or from source, or...).
I am not so sure about that. Why should the number of packages
matter? We could argue that the current splitting of RPM
packages is half-done in that sense --- we lack the "tying
together" package which itself is empty but depends on
subpackages that implements common client-side. Call that
git-scm (or "git") and have the end users install it, then it
would pull what it depends on along with it. No?
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Junio C Hamano @ 2005-11-14 7:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4375DD4A.5050103@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> Also places we execute git-upload-pack and git-receive-pack over
>> an SSH connection need to be updated to execute 'git' with the
>> first parameter 'upload-pack' and 'receive-pack' to make sure it
>> would keep working with older or newer git on the other end.
>
> I've cooked up a patch that takes care of this if;
> git daemon
> is executed (rather than git-daemon)...
Actually I was more worried about these git native protocols
going over ssh, which is not helped by git-daemon. I think
teaching the libdir to git-shell would make sense for "git
restricted shell" users, but most users coming from ssh to run
git native protocols would need to have some way of running the
executable on the other end.
My current thinking about this problem is that the handful
programs that need to run "on the other end" should stay in
/usr/bin, even after we move most things out of /usr/bin, if
only to avoid configuration hassles. They are:
receive-pack, upload-pack
ssh-fetch, ssh-pull, ssh-push, ssh-upload
BTW, does anybody actually use these commit walkers over SSH?
Cogito switched out of it before 0.16r1 if I understand
correctly, and git barebone never used it. It might not be a
bad idea to deprecate these altogether, now packed transfer
seems to be much nicer.
BTW^2, git-octopus should be deprecated as well; I am a bit
reluctant to see git-resolve go but it probably should too.
> All I really need to finalize it is that name, so It's up to you how
> fast you want it. Perhaps we could take a poll?
Somehow libdir reminds me of where libraries are installed by
the Makefile, which usually does not mean executables, and that
was the reason I mentioned --exec-path. Although I do not have
strong preference myself either way, I do not think the list
cares too much either, so in order not to waste time by
indecision, let's just say we use this one:
> The form will be
> exec_path=$(prefix)/lib/git-@@VERSION@@
> GIT_EXEC_PATH
> --exec-path
>
> for Makefile, environment and 'git', respectively. Substitute the
> obvious part with whatever you prefer.
> ..., although I'm implementing Linus' idea of prepending the
> GIT_EXEC_PATH to $PATH so the porcelainish scripts in git-core
> shouldn't have to do it.
This sounds good to me; let's go with it. Thanks.
^ permalink raw reply
* Re: GIT character codecs
From: Matthias Urlichs @ 2005-11-14 7:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20051114063126.27817.qmail@web26306.mail.ukl.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
Hi,
Marco Costalba:
> >Or, if you want to be super-flexible, just try to decode as UTF-8.
> >Success? fine -- otherwise use whatever your application's default is
> >set to, or your local encoding (which may of course also be UTF-8), or
> >fall back to 8859-15.
>
> How it is possible to test for success?
UTF-8 decoding does NOT always succeed.
In fact, there is no other 8-bit encoding which decodes as valid UTF-8,
given real-world text.
> The codec could see everything decodable, but It's only from the
> context, i.e. the user who reads, that it is possible to realize it's
> the wrong codec.
>
True in general, but not with UTF-8 (or ASCII, for that matter ;-).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
You can fool the people about many things, but only a fool would be foolish
enough to fool the people about money.
-- Italo Bombolini
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT character codecs
From: Marco Costalba @ 2005-11-14 6:31 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
Matthias Urlichs wrote:
>Hi, Junio C Hamano wrote:
>
>>I suspect you could just take the default from LANG and LC_CTYPE
>>to cover 98% of the cases, and to cover the rest 2% the
>>problematic cases have a per-window override menu.
>
>
>Or, if you want to be super-flexible, just try to decode as UTF-8.
>Success? fine -- otherwise use whatever your application's default is
>set to, or your local encoding (which may of course also be UTF-8), or
>fall back to 8859-15.
>
How it is possible to test for success?
The codec could see everything decodable, but It's only from the context,
i.e. the user who reads, that it is possible to realize it's the wrong codec.
Anyhow, as I posted previous in this thread, qgit-0.97.2 now has a codec selector
as a persistent setting, defaulting to local codec.
Marco
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Junio C Hamano @ 2005-11-14 6:06 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511132001x6a9109fk17593b7ceaf3177e@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> On 11/14/05, Junio C Hamano <junkio@cox.net> wrote:
>> In your message you indicated that you use "format-patch" piped
>> to "am". I think that is a better approach than "rebase" these
>> days
>
> Hmmm. But doesn't deal well with binary changes. We deal with a large
> set of projects, and while we don't manage that many binary files, it
> is just enough that I'll have to pass on only using format-patch.
It shouldn't be too tricky to enhance "git am" (git-apply called
at around line 49 in it) to grok binary differences for this
purpose, because you would have both pre- and post-image blob in
your object database, because the patch is being used only to
replay what you have in your reository, and it records their
abbreviated SHA1 name.
I've never felt need to "merge" the binary files myself and had
never got around doing this, but if you are interested, it would
go something like this:
. Make "index %.7s..%.7s" that abbreviates pre- and post- image
blob SHA1s in diff.c configurable to spit out full 40 bytes.
Call that option --full-index-sha1.
. The updated "git rebase" that uses the "format-patch | am" I
outlined would pass the --full-index-sha1 to format-patch
(which is pased onto underlying diff-tree -p).
. In apply.c, check if all of the following holds:
* we have both the full 40-byte old_sha1_prefix[] and
new_sha1_prefix[]; and
* what the index records matches old_sha1_prefix[]; and
* the new blob is found in the object database;
and for such a path:
* change parse_chunk() not to barf even on a binary patch.
* change apply_data() to just declare the patch application
result is the new blob recorded in the patch.
Hmm.
^ permalink raw reply
* Re: Balanced packing strategy
From: Craig Schlenter @ 2005-11-14 5:03 UTC (permalink / raw)
To: Josef Weidendorfer, git; +Cc: Petr Baudis
Hi
> From: Josef Weidendorfer [mailto:Josef.Weidendorfer@gmx.de]
> [snip]
> AFAICS, the git native protocol (which is nothing more than a pack itself
> for each transfer) even has this problem, too: If you are updating every
> day via git native, the sum of transfered bytes in a month will be a
> multiple of one git transfer for all the month's changes.
Interesting ... is this because in a bigger pack the compression will
be better as there is probably more stuff to "delta" against?
--Craig
^ permalink raw reply
* Re: GIT character codecs
From: Matthias Urlichs @ 2005-11-14 4:47 UTC (permalink / raw)
To: git
In-Reply-To: <7v3bm0c0gf.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> I suspect you could just take the default from LANG and LC_CTYPE
> to cover 98% of the cases, and to cover the rest 2% the
> problematic cases have a per-window override menu.
Or, if you want to be super-flexible, just try to decode as UTF-8.
Success? fine -- otherwise use whatever your application's default is
set to, or your local encoding (which may of course also be UTF-8), or
fall back to 8859-15.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Difficult:
Disciplines like physics, math, engineering, which is why I don't
want to do them.
-- Fashionable Dictionary (www.butterfliesandwheels.com)
^ permalink raw reply
* Re: Regarding: git-lost+found
From: Matthias Urlichs @ 2005-11-14 4:36 UTC (permalink / raw)
To: git
In-Reply-To: <7vvez1bjjv.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> $ gitk $(cd .git/lost+found/commit && echo ??*)
Along those lines... I just tried that, it found a whole heap of old
commits I didn't yet clean up, and they're sorted by their SHA1.
In other words, actually finding the latest commit in there was a
nontrivial task.
I don't speak tcl, so could somebody please change "gitk -d" to sort its
command line by date (newest first, of course)? Thanks.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Innocence ends when one is stripped of the delusion that one likes
oneself.
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Martin Langhoff @ 2005-11-14 4:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkzr6gzz.fsf@assigned-by-dhcp.cox.net>
On 11/14/05, Junio C Hamano <junkio@cox.net> wrote:
> In your message you indicated that you use "format-patch" piped
> to "am". I think that is a better approach than "rebase" these
> days
Hmmm. But doesn't deal well with binary changes. We deal with a large
set of projects, and while we don't manage that many binary files, it
is just enough that I'll have to pass on only using format-patch.
> This was recently added by Linus to help git-merge do that:
>
> git-read-tree --trivial -m -u $O $A $B
Cool! Abusing that, perhaps I could teach git-rebase to take a
'--trivial-only' flag, and then cg-update --rebase could try
git-rebase --trivial-only, and fall back on cg-merge...
cheers,
martin
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Junio C Hamano @ 2005-11-14 3:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511131242p4692c74fn20c015998620b9f4@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> On 11/13/05, Junio C Hamano <junkio@cox.net> wrote:
>> .... I
>> could do "git pull . origin" at this point, but that would
>> result in a useless mini-merge. My tree is not public so I can
>> freely rebase to clean things up.
>>
>> $ git rebase origin
>> $ git show-branch
>
> What happens if there are conflicts during git-rebase?
Well, obviously you could resolve them ;-). But if you are
rebasing just to reduce trivial mini-merges, it might make more
sense to honestly record the merge if the rebase involves
conflict resolution. After all, the reason rebase got conflicts
is because the development trail by somebody else that has been
already committed to the shared "master" branch overlapped what
you were doing in your "master" branch, isn't it?
In your message you indicated that you use "format-patch" piped
to "am". I think that is a better approach than "rebase" these
days; the conflict can be handled easier with that approach, and
if you use "--3way" flag you do not even have to worry about
patches in your branch that is already there in the shared
"master" (your "origin") branch.
So instead of running "git rebase origin" at this point, I may
do something like this [*1*]:
$ git-reset --hard origin
$ git-format-patch -k --stdout origin ORIG_HEAD | git am -3 -k
The first step rewinds my "master" (the original is stored in
ORIG_HEAD), and the second step extracts the commits that were
in my master but not in origin in a patch form, an replay them
on top of the "master" (which was rewound to "origin").
"git-am" would stop at the first unapplicable patch if there is
a conflict, leaving the conflicting patch in .dotest/patch.
I have to fix it up before going further. Here is how.
1. "git am" 3-way fallback would have kicked in, because I have
all the blobs the patch is supposed to apply to, and my
working tree and index is in a state just like when I am
resolving a conflicting merge after a pull. Clean up the
conflict in the working tree, build-test and all as usual.
2. Run "git diff HEAD >.dotest/patch" to record what the patch
should have been if it were to apply cleanly on top of the
previous state. If I did a noteworthy adjustment to the
patch, I might also edit .dotest/final-commit to update the
commit log message.
3. Then reset the working tree and index before the failed
application of this patch with "git reset --hard".
After that:
$ git am -3
would let me restart from that commit that did not replay well.
> Is there a cheap way to ask from a shell script whether the merge is
> truly trivial? I thought git-diff-tree would help me here, but it
> doesn't...
This was recently added by Linus to help git-merge do that:
git-read-tree --trivial -m -u $O $A $B
The command exits with a non-zero status, without touching index
nor working tree, when the merge is not "truly trivial".
Otherwise it does its thing -- the trivial in-index merge is
done, files in working tree updated and the only thing left for
you to do is to create a commit having parent $A and $B.
Would that help?
[Footnote]
*1* This is what the "make rebase restartable" comment in TODO
list is about, and I wanted to rewrite "rebase" to do exactly
these two commands, but I got distracted ;-).
^ permalink raw reply
* Re: [PATCH 5/5] -D <depth> option to recurse into merged branches
From: Eric Wong @ 2005-11-14 2:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list
In-Reply-To: <20051112093208.GF16218@Muzzle>
One small fix on top of this one:
Don't check for parents if the only revision we have is a base-0
and @psets is empty.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-archimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 8a7e18ff0884cae74a1127d5c96577a85acca3f4
5f2896558284724bcc87eb64daa0933b544ec20d
diff --git a/git-archimport.perl b/git-archimport.perl
index a0ea016..b624ba6 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -186,7 +186,7 @@ sub do_abrowse {
if (%ps && !exists $psets{ $ps{id} }) {
my %temp = %ps; # break references
- if ($psets[$#psets]{branch} eq $ps{branch}) {
+ if (@psets && $psets[$#psets]{branch} eq $ps{branch}) {
$temp{parent_id} = $psets[$#psets]{id};
}
push (@psets, \%temp);
---
0.99.9.GIT
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox