* Re: If you would write git from scratch now, what would you change?
From: Marco Costalba @ 2007-11-26 19:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <fiet88$68n$1@ger.gmane.org>
On Nov 26, 2007 5:46 PM, Andy Parkins <andyparkins@gmail.com> wrote:
> Jakub Narebski wrote:
>
> > If you would write git from scratch now, from the beginning, without
> > concerns for backwards compatibility, what would you change, or what
> > would you want to have changed?
>
> Erm... (it's much harder to come with lists like these lately :-))
>
> - "git-gui" would be written in Qt (ducks)
But...wait...Qt would require...(I'm scared to say!)... that awful,
painful, hopeless thing called C++. Probably you didn't mean what you
said ;-)
Marco
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jan Hudec @ 2007-11-26 19:27 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <858x4l2apc.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > If you would write git from scratch now, from the beginning, without
> > concerns for backwards compatibility, what would you change, or what
> > would you want to have changed?
>
> Get rid of plumbing at the command line level. It is confusing to
No, please. It's extremely useful. It should be a bit more hidden, but it's
a big advantage of git that the plumbing is available.
> users, and command line arguments, exec calls and I/O streams are not
> efficient and reasonably typed mechanisms for the kind of operations
> done in plumbing. Instead using a good extensible portable scripting
> language (I consider Lua quite suitable in that regard, but it is
> conceivable that something with a native list type supporting easy
> sorts, merges and selections could be more efficient) and implementing
> plumbing in that or in C would have been preferable for creating the
> porcelain.
POSIX shell is really the best extensible portable scripting language
available for the job. Because the whipuptitude is the most important
property and shell is simply best at one-liners. And since you use it
for regular work (running editor, compiler, git porcelain), it is the
obvious choice for whiping up a short function.
> That would keep plumbing out of the hair of users and make it easier to
> cobble together extensions and variations with non-trivial internal
> dataflow.
>
> Shell scripts have also proven to be a constant hassle with regard to
> portability and bugs (like underquoting).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-26 19:30 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <858x4l2apc.fsf@lola.goethe.zz>
On Mon, 26 Nov 2007, David Kastrup wrote:
> Get rid of plumbing at the command line level.
We can't get rid of plumbing. It is part of Git probably forever and is
really really convenient for scripting in any language you want.
The only valid argument IMHO is the way too large number of Git commands
directly available from the cmdline.
The solution: make purely plumbing commands _not_ directly available
from the command line. Instead, they can be available through 'git
lowlevel <blah>' instead of 'git <blah>' and only 'git lowlevel' would
stand in your shell default path.
Such a scheme can be implemented in parallel with the current one for a
release while the direct plumbing commands are deprecated in order to
give script authors a transition period to fix their code.
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: David Kastrup @ 2007-11-26 19:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261417580.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 26 Nov 2007, David Kastrup wrote:
>
>> Get rid of plumbing at the command line level.
>
> We can't get rid of plumbing.
What about "at the command line level" did you not understand?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jan Hudec @ 2007-11-26 19:34 UTC (permalink / raw)
To: David Kastrup; +Cc: Benoit Sigoure, Andy Parkins, git
In-Reply-To: <85prxw253u.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]
On Mon, Nov 26, 2007 at 20:12:37 +0100, David Kastrup wrote:
> Jan Hudec <bulb@ucw.cz> writes:
>
> > On Mon, Nov 26, 2007 at 18:10:10 +0100, Benoit Sigoure wrote:
> >> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:
> >> While we're discussing bad names, as someone already pointed out, I agree
> >> it's sad that "git push" is almost always understood as being the opposite
> >> of "git pull".
> >
> > Well, it is an oposite of pull. Compared to it, it is limited in that it will
> > not do a merge and on the other hand extended to *also* be an oposite of
> > fetch, but still oposite of pull is push.
>
> With the same reasoning the opposite of a duck is a lobster, since a
> lobster has not only fewer wings, but also more legs.
No.
The basic pull/push actions are:
git pull: Bring the remote ref value here.
git push: Put the local ref value there.
Are those not oposites?
Than each command has it's different features on top of this -- pull merges
and push can push multiple refs -- but in the basic operation they are
oposites.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Making ce_path_match() more useful by accepting globs
From: Alex Riesen @ 2007-11-26 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vlk8lj1b7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Mon, Nov 26, 2007 01:30:20 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Junio C Hamano, Sun, Nov 25, 2007 19:03:12 +0100:
> >> Currently ce_path_match() only uses "the leading directory" match, and
> >> does not understand file globs. These do not work:
> >>
> >> git diff-files 't/*.sh'
> >> git diff-index HEAD 'xdiff/*.c'
> >> git update-index -g 'Documentation/howto/*.txt'
> >
> > How should my scripts handle files with "*" in names?
>
> We DO NOT CARE.
>
> Why?
>
> How would you handle such files from the command line session without
> git? "ls such-*-a-file" will also show such-silly-a-file as well.
It will break existing setups. Something like
#!/bin/bash
git diff-files --quiet -- "$@" || do_something
will behave differently
> IOW, the user is shooting in the foot --- and at that point I am not all
> that interested in helping him.
What with? What's wrong with a name like "M*A*S*H" in your personal IMDB?
> Having said that, I would think that quoting the meta from fnmatch(3)
> like this:
>
> git ls-files 'such-\*-a-file'
>
> would work fine, just like
>
> ls such-\*-a-file
>
> would.
An existing system will still be broken.
> If "ls such-*-a-file" reports only one file,
>
> git ls-files 'such-*-a-file'
>
> would also report that file as well.
>
> So in practice I do not see a problem.
I think I do. There is NO way to pass the filenames to git plumbing
(only the diff-, or is git update-index --stdin -z also subject to
glob expansion?) without being sure they are exactly they were on
filesystem. Quoting is just PITA for scripting.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Michael Poole @ 2007-11-26 19:50 UTC (permalink / raw)
To: Jan Hudec; +Cc: David Kastrup, Benoit Sigoure, Andy Parkins, git
In-Reply-To: <20071126193455.GC25784@efreet.light.src>
Jan Hudec writes:
> The basic pull/push actions are:
>
> git pull: Bring the remote ref value here.
> git push: Put the local ref value there.
>
> Are those not oposites?
>
> Than each command has it's different features on top of this -- pull merges
> and push can push multiple refs -- but in the basic operation they are
> oposites.
I think that is in absolute agreement with David: Ducks swim on the
surface of the water and lobsters swim underneath. Why consider the
different features on top of where they swim?
The thing about git-pull that surprises so many users is the merge.
There's a separate command to do that step, and git-pull had a fairly
good excuse to do the merge before git's 1.5.x remote system was in
place, but now the only really defensible reason for its behavior is
history.
Michael Poole
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-26 19:52 UTC (permalink / raw)
To: Dana How; +Cc: Jakub Narebski, git
In-Reply-To: <56b7f5510711261118m7a402beah5d9cb75c1ad10b43@mail.gmail.com>
On Mon, 26 Nov 2007, Dana How wrote:
> Currently data can be quickly copied from pack to pack,
> but data cannot be quickly copied blob->pack or pack->blob
I don't see why you would need the pack->blob copy normally.
> (there was an alternate blob format that supported this,
> but it was deprecated). Using the pack format for blobs
> would fix this.
Then you can do just that for big enough blobs where "big enough" is
configurable: encapsulate them in a pack instead of a loose object.
Problem solved. Sure you'll end up with a bunch of packs containing
only one blob object, but given that those blobs are so large to be a
problem in your work flow when written out as loose objects, then they
certainly must be few enough not to cause an explosion in the number of
packs.
> It would also mean blobs wouldn't need to
> be uncompressed to get the blob type or size I believe.
They already don't.
> So far this has prevented me from deploying git here
> (and is half the reason I have not been active recently).
> Currently we use p4 and we have large files.
> When a large file is checked in (submitted),
> it is compressed *once* and sent over the network --
> these are the only delays that end-users experience.
>
> The equivalent operation in git would require the creation of
> the blob, and then of a temporary pack to send to the server.
> This requires 3 calls to zlib for each blob, which for very
> large files is not acceptable at my site.
I currently count 2 calls to zlib, not 3. And with big blobs as packs,
as suggested above then you'd have only one call when actually staging
their content. This should be really straight forward to implement
given that pack-objects is already a built-in.
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] Making ce_path_match() more useful by accepting globs
From: Alex Riesen @ 2007-11-26 19:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vsl2ujc6x.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Sun, Nov 25, 2007 21:35:18 +0100:
> Currently, these do not work:
>
> git diff-files 't/*.sh'
> git diff-index HEAD 'xdiff/*.c'
> git update-index -g 'Documentation/howto/*.txt'
>
> This is because ce_path_match(), the underlying function that is used to
> see if a cache entry matches the set of pathspecs, only understands
> leading directory match.
>
> This teaches ce_path_match() to use the match_pathspec() used in
> git-ls-files, which knows about glob patterns.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> [SORRY FOR A RESEND -- I screwed up the To: field of the previous message]
>
> * Having two different behaviours of pathspec matching has been
> bothering me for quite some time. The changes here look trivially
> correct and the result passes all the tests, but this is quite close
> to the core part of the system, and would benefit greatly from extra
> set of eyes.
How about doing the same what was done with recursive directory
walker (no, I'm not confusing pathname filters with paths)? Always
have the glob expansion for porcelain (git-diff, git-log, git-show),
and add a command-line option to activate for plumbing?
(Well, the oldtimers as yourself will probably find it hard to
separate git-diff-tree from git-diff).
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jan Hudec @ 2007-11-26 19:57 UTC (permalink / raw)
To: David Kastrup; +Cc: Nicolas Pitre, Jakub Narebski, git
In-Reply-To: <854pf8243i.fsf@lola.goethe.zz>
On Mon, Nov 26, 2007 at 20:34:25 +0100, David Kastrup wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > On Mon, 26 Nov 2007, David Kastrup wrote:
> >> Get rid of plumbing at the command line level.
> >
> > We can't get rid of plumbing.
>
> What about "at the command line level" did you not understand?
Which part of we neither can nor want did you not understant?
The availability of plumbing is really big part of a reason why git is so
good and has so many scripts and tool built on top of it. Bzr and hg boast
with their ability to add plugins, but git ability to use plumbing simply
beats that hands down, because the plugins are python-only and writing them
requires understanding the internal API, while git plumbing can be used from
any language and can usually be understood by running it interactively a few
times.
That's why we don't want (and really can't because there is a huge amount of
code in various languages using it) to get rid of plumbing at the command
level. What we may do is hide it from the casual user.
To do that, we'd want to get rid of the git-* commands and links in bin
(remove the builtins altogether and move the non-builtin to libexec -- that
seems to be the plan for 1.6 or 1.7 already) and than hiding the plumbing
from --help and completion hides it from the user.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* (unknown)
From: Michael Dressel @ 2007-11-26 20:00 UTC (permalink / raw)
To: bulb; +Cc: git
>On Mon, Nov 26, 2007 at 20:12:37 +0100, David Kastrup wrote:
>> Jan Hudec <bulb@ucw.cz> writes:
>>
>> > On Mon, Nov 26, 2007 at 18:10:10 +0100, Benoit Sigoure wrote:
>> >> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:
>> >> While we're discussing bad names, as someone already pointed out, I
agree
>> >> it's sad that "git push" is almost always understood as being the
opposite
>> >> of "git pull".
>> >
>> > Well, it is an oposite of pull. Compared to it, it is limited in that
it will
>> > not do a merge and on the other hand extended to *also* be an oposite
of
>> > fetch, but still oposite of pull is push.
>>
>> With the same reasoning the opposite of a duck is a lobster, since a
>> lobster has not only fewer wings, but also more legs.
>
>No.
>
>The basic pull/push actions are:
>
>git pull: Bring the remote ref value here.
>git push: Put the local ref value there.
>
>Are those not oposites?
>
>Than each command has it's different features on top of this -- pull
>merges
>and push can push multiple refs -- but in the basic operation they are
>oposites.
In the case remote branches are used push and pull are not exactly
opposite. Pull uses the remote branch and push does not.
.
LOCAL REPO . REMOTE REPO
.............................................................
a_local_branch ------------ push ------------->a_local_branch
^ . |
| . |
| . |
merge . |
| . |
| . |
a_remote_branch <----------fetch ---------------------
.
Cheers,
Michael
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jan Hudec @ 2007-11-26 20:09 UTC (permalink / raw)
To: Michael Poole; +Cc: David Kastrup, Benoit Sigoure, Andy Parkins, git
In-Reply-To: <87ve7ozsz8.fsf@graviton.dyn.troilus.org>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
On Mon, Nov 26, 2007 at 14:50:35 -0500, Michael Poole wrote:
> Jan Hudec writes:
>
> > The basic pull/push actions are:
> >
> > git pull: Bring the remote ref value here.
> > git push: Put the local ref value there.
> >
> > Are those not oposites?
> >
> > Than each command has it's different features on top of this -- pull merges
> > and push can push multiple refs -- but in the basic operation they are
> > oposites.
>
> I think that is in absolute agreement with David: Ducks swim on the
> surface of the water and lobsters swim underneath. Why consider the
> different features on top of where they swim?
>
> The thing about git-pull that surprises so many users is the merge.
> There's a separate command to do that step, and git-pull had a fairly
> good excuse to do the merge before git's 1.5.x remote system was in
> place, but now the only really defensible reason for its behavior is
> history.
When I first looked at hg -- and that was long before I looked at git --
I was surprised that their pull did NOT merge and you had to do a separate
step. Partly because doing those two steps is quite common.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Andy Parkins @ 2007-11-26 20:11 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git
In-Reply-To: <2A34D324-48A4-49EF-9D4E-5B9469A0791D@lrde.epita.fr>
On Monday 2007, November 26, Benoit Sigoure wrote:
> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:
> > - libgit would have come first
>
> I warmly second that.
>
> > - "git revert" should be called "git invert"
> > - "git revert" would (maybe) be "git reset"
>
> But here, I have to disagree. Why would you want to call "git-
> revert" "git-reset"?
I don't; you're reading it the wrong way around. I think current revert
should actually be called invert. "revert" means to move back to a
previous point. That is not at all what git-revert does, what it actually
does is to apply the opposite of the given commit - i.e. an inversion.
Revert on the other hand would be the perfect name for current git-reset.
> I know it's annoying that commands with the same name do different
> things in SVN/CVS but I don't think it's a reason to necessarily
I know that very well; nor did I pick any of those suggestions based on what
svn does. There is no other VCS that uses "invert" as far as I know. Nor
does any other VCS use "revert" the way I'd like; so I'm really not sure
where you're getting the idea that I chose those as a copy of another VCS.
What I would like (ideally, with a time machine) is those words, which have
a well defined meaning in English, to match more closely with their
function in the VCS. "revert" is definitely not right.
> adapt to them. There are plenty of misnomers already anyway
> (checkout, commit, add).
I know; but the question was "what if we could start again". I don't see
too many problems with checkout and commit as it happens. They both seem
like adequate verbs to describe the operations they perform. We could
perhaps quibble about the extra functionality that they've both gained, but
that isn't a naming fault, and the extensions are natural extensions for
users of git.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Benoit Sigoure @ 2007-11-26 20:11 UTC (permalink / raw)
To: Jan Hudec; +Cc: David Kastrup, Jakub Narebski, git
In-Reply-To: <20071126192703.GB25784@efreet.light.src>
On Nov 26, 2007, at 8:27 PM, Jan Hudec wrote:
> On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> If you would write git from scratch now, from the beginning, without
>>> concerns for backwards compatibility, what would you change, or what
>>> would you want to have changed?
>>
>> Get rid of plumbing at the command line level. It is confusing to
>
> No, please. It's extremely useful. It should be a bit more hidden,
> but it's
> a big advantage of git that the plumbing is available.
>
>> users, and command line arguments, exec calls and I/O streams are not
>> efficient and reasonably typed mechanisms for the kind of operations
>> done in plumbing. Instead using a good extensible portable scripting
>> language (I consider Lua quite suitable in that regard, but it is
>> conceivable that something with a native list type supporting easy
>> sorts, merges and selections could be more efficient) and
>> implementing
>> plumbing in that or in C would have been preferable for creating the
>> porcelain.
>
> POSIX shell is really the best extensible portable scripting language
> available for the job. Because the whipuptitude is the most important
> property and shell is simply best at one-liners. And since you use it
> for regular work (running editor, compiler, git porcelain), it is the
> obvious choice for whiping up a short function.
Perl seems pretty portable. If we had a decent, complete libgit, it
would be easy to create bindings for various languages and script Git
in other languages than Shell script.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jakub Narebski @ 2007-11-26 20:17 UTC (permalink / raw)
To: Dana How; +Cc: git, Nicolas Pitre
In-Reply-To: <56b7f5510711261118m7a402beah5d9cb75c1ad10b43@mail.gmail.com>
On Mon, 26 Nov 2007, Dana How wrote:
> On Nov 25, 2007 1:48 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> > If you would write git from scratch now, from the beginning, without
> > concerns for backwards compatibility, what would you change, or what
> > would you want to have changed?
>
> Currently data can be quickly copied from pack to pack,
> but data cannot be quickly copied blob->pack or pack->blob
> (there was an alternate blob format that supported this,
> but it was deprecated). Using the pack format for blobs
> would fix this. It would also mean blobs wouldn't need to
> be uncompressed to get the blob type or size I believe.
Could you do some benchmark for repository with your large objects
as loose objects created with and without core.legacyHeaders (created
with git pre 1.5.3), and as single blob packs, perhaps kept, with
_undocumented_ (except for RelNotes) gitattribute delta unset for
those files?
>From Documentation/RelNotes-1.5.3:
- We used to have core.legacyheaders configuration, when
set to false, allowed git to write loose objects in a format
that mimicks the format used by objects stored in packs. It
turns out that this was not so useful. Although we will
continue to read objects written in that format, we do not
honor that configuration anymore and create loose objects in
the legacy/traditional format.
- "pack-objects" honors "delta" attribute set in
.gitattributes. It does not attempt to deltify blobs that
come from paths with delta attribute set to false.
- diff-delta code that is used for packing has been improved
to work better on big files.
The last part is thanks to your comments, complaints and efforts, Dana.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Dana How @ 2007-11-26 20:17 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git, danahow
In-Reply-To: <alpine.LFD.0.99999.0711261433210.9605@xanadu.home>
On Nov 26, 2007 11:52 AM, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 26 Nov 2007, Dana How wrote:
> > Currently data can be quickly copied from pack to pack,
> > but data cannot be quickly copied blob->pack or pack->blob
> I don't see why you would need the pack->blob copy normally.
True, but that doesn't change the main point.
> > (there was an alternate blob format that supported this,
> > but it was deprecated). Using the pack format for blobs
> > would fix this.
>
> Then you can do just that for big enough blobs where "big enough" is
> configurable: encapsulate them in a pack instead of a loose object.
> Problem solved. Sure you'll end up with a bunch of packs containing
> only one blob object, but given that those blobs are so large to be a
> problem in your work flow when written out as loose objects, then they
> certainly must be few enough not to cause an explosion in the number of
> packs.
Are you suggesting that "git add" create a new pack containing
one blob when the blob is big enough? Re-using (part of) the pack format
in a blob (or maybe only some blobs) seems like less code change.
> > It would also mean blobs wouldn't need to
> > be uncompressed to get the blob type or size I believe.
>
> They already don't.
It looks like sha1_file.c:parse_sha1_header() works on a buffer
filled in by sha1_file.c:unpack_sha1_header() by calling inflate(), right?
It is true you don't have to uncompress the *entire* blob.
> > The equivalent operation in git would require the creation of
> > the blob, and then of a temporary pack to send to the server.
> > This requires 3 calls to zlib for each blob, which for very
> > large files is not acceptable at my site.
>
> I currently count 2 calls to zlib, not 3.
I count 3:
Call 1: git-add calls zlib to make the blob.
Call 2: builtin-pack-objects.c:write_one() calls sha1_file.c:read_sha1_file()
calls :unpack_sha1_file() calls :unpack_sha1_{header,rest}() calls
inflate() to get the data from the blob into a buffer.
Call 3: Then write_one() calls deflate to make the new buffer
to write into the pack. This is all under the "if (!to_reuse) {" path,
which is active when packing a blob.
Remember, I'm comparing "p4 submit file" to
"git add file"/"git commit"/"git push", which is the comparison
the users will be making.
On the other hand, I'm looking at code from June;
but I haven't noticed big changes since then on the list.
Calls 2 and 3 go away if the blob and pack formats were more similar.
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-26 20:25 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <85lk8k24ju.fsf@lola.goethe.zz>
On Mon, 26 Nov 2007, David Kastrup wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > [ I get really really annoyed when your replies to me aren't directly
> > addressed to me, Jakub. Told you so repeatedly in the past as well.
> > Why are you the only one on this list apparently not able to use a
> > proper email setup? ]
>
> X-Injected-Via-Gmane: http://gmane.org/
>
> And Jakub by far is not the only one using gmane for reading and writing
> to the list.
It is strange, though, that Jakub is the only one I've noticed who isn't
able to do me the courtesy of addressing me directly when replying to
me.
> I am reading and writing on a number of mailing lists with either
> explicit or implicit gateways to news servers. But the git mailing list
> is the only one where I ever encountered a semi-permanent stream of
> (sometimes quite rude) complaints because people insist on getting
> replies at least twice: once by the mailing list, and once by personal
> Email. In contrast to claims made here, it is _not_ common netiquette
> to create extra personal copies.
We must not live in the same virtual world then. This _is_ common
netiquette in the Linux world.
I get over 500 emails a day. I can thread them just like a news
reader would do. But I do sort them in different folders as well. My
most important folder contains emails directly sent to me, or on which
I'm CC'd. The other folders might get completely ignored when I'm too
busy, or threads quickly purged out.
> In fact, for articles sent through
> Usenet servers, it is generally considered an _annoyance_ to include
> unannounced "courtesy copies" since replies to them will not usually
> reach the list and will require redoing.
This is a mailing list and not a news group. I don't care if you use a
newsgroup gateway if it isn't broken. As it is, gmane is broken as far
as I'm concerned.
So please complain to gmane or change your setup.
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Michael Poole @ 2007-11-26 20:31 UTC (permalink / raw)
To: Jan Hudec; +Cc: David Kastrup, Benoit Sigoure, Andy Parkins, git
In-Reply-To: <20071126200913.GE25784@efreet.light.src>
Jan Hudec writes:
> On Mon, Nov 26, 2007 at 14:50:35 -0500, Michael Poole wrote:
>> Jan Hudec writes:
>>
>> > The basic pull/push actions are:
>> >
>> > git pull: Bring the remote ref value here.
>> > git push: Put the local ref value there.
>> >
>> > Are those not oposites?
>> >
>> > Than each command has it's different features on top of this -- pull merges
>> > and push can push multiple refs -- but in the basic operation they are
>> > oposites.
>>
>> I think that is in absolute agreement with David: Ducks swim on the
>> surface of the water and lobsters swim underneath. Why consider the
>> different features on top of where they swim?
>>
>> The thing about git-pull that surprises so many users is the merge.
>> There's a separate command to do that step, and git-pull had a fairly
>> good excuse to do the merge before git's 1.5.x remote system was in
>> place, but now the only really defensible reason for its behavior is
>> history.
>
> When I first looked at hg -- and that was long before I looked at git --
> I was surprised that their pull did NOT merge and you had to do a separate
> step. Partly because doing those two steps is quite common.
Frequency of use is a good argument for having one command that does
both. It is not a good argument that "fetch, then merge" should be
called "pull" or is the opposite of "push".
Michael Poole
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: David Kastrup @ 2007-11-26 20:35 UTC (permalink / raw)
To: Jan Hudec; +Cc: Nicolas Pitre, Jakub Narebski, git
In-Reply-To: <20071126195750.GD25784@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> On Mon, Nov 26, 2007 at 20:34:25 +0100, David Kastrup wrote:
>> Nicolas Pitre <nico@cam.org> writes:
>> > On Mon, 26 Nov 2007, David Kastrup wrote:
>> >> Get rid of plumbing at the command line level.
>> >
>> > We can't get rid of plumbing.
>>
>> What about "at the command line level" did you not understand?
>
> Which part of we neither can nor want did you not understant?
>
> The availability of plumbing is really big part of a reason why git is
> so good and has so many scripts and tool built on top of it.
Which is the reason I proposed making the plumbing available at a
scripting level, not at the command line level.
The actual trend we are getting nowadays is locking the porcelaine,
previously available as shell scripts, down into C code, _without_
making use of a reasonable plumbing layer suitable for any scripting at
all.
So the git community at the same time praises shell scripting and
simultanouesly replaces it without even using the available plumbing,
_and_ claims that _both_, exclusive and incompatible approaches, are the
perfect solution. At the same time. While fighting the shell
portability fight continuously, on Unix as well as Windows.
I may have a big mouth, but swallowing all of this at once is beyond me.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Dana How @ 2007-11-26 20:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Nicolas Pitre, danahow
In-Reply-To: <200711262117.56326.jnareb@gmail.com>
On Nov 26, 2007 12:17 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 26 Nov 2007, Dana How wrote:
> > On Nov 25, 2007 1:48 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > > If you would write git from scratch now, from the beginning, without
> > > concerns for backwards compatibility, what would you change, or what
> > > would you want to have changed?
> >
> > Currently data can be quickly copied from pack to pack,
> > but data cannot be quickly copied blob->pack or pack->blob
> > (there was an alternate blob format that supported this,
> > but it was deprecated). Using the pack format for blobs
> > would fix this. It would also mean blobs wouldn't need to
> > be uncompressed to get the blob type or size I believe.
>
> Could you do some benchmark for repository with your large objects
> as loose objects created with and without core.legacyHeaders (created
> with git pre 1.5.3), and as single blob packs, perhaps kept, with
> _undocumented_ (except for RelNotes) gitattribute delta unset for
> those files?
First of all, this is a very reasonable request and what I should be doing.
Unfortunately, I only have the cycles at the moment to point out this
issue, which appears to be a problem from my perspective.
Currently,
a user who wants to publish some (large) files does the following:
git add (calls deflate)
git commit
git push (builds a pack to stdout, calling inflate and deflate on each blob).
So if the blob and pack formats were more similar (different blob format,
big blobs are singleton packs, etc) the zlib calls in git push go away.
The deflate call could be sped up by using 1 for compression level,
but it still takes time.
Another "solution" is to make each workgroup member's .git/objects
be a symlink to a tree with a lot of sticky bits and do some scripting.
(This means "git push" doesn't push any data and only alters stuff
in .git/refs/heads on the server.)
I'm not entirely enthusiastic about this, and when I mentioned it a while
ago it did cause some retching...
> From Documentation/RelNotes-1.5.3:
>
> - We used to have core.legacyheaders configuration, when
> set to false, allowed git to write loose objects in a format
> that mimicks the format used by objects stored in packs. It
> turns out that this was not so useful. Although we will
> continue to read objects written in that format, we do not
> honor that configuration anymore and create loose objects in
> the legacy/traditional format.
>
> - "pack-objects" honors "delta" attribute set in
> .gitattributes. It does not attempt to deltify blobs that
> come from paths with delta attribute set to false.
>
> - diff-delta code that is used for packing has been improved
> to work better on big files.
>
> The last part is thanks to your comments, complaints and efforts, Dana.
Yes, there have been some very useful improvements recently.
However, I didn't actually push for the first "-" you list;
I was pushing for the "mimic" option even then
but some argument was presented to me against it,
to which I had no counter-argument until I understood git better later.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jan Hudec @ 2007-11-26 20:36 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: David Kastrup, Jakub Narebski, git
In-Reply-To: <FF804F69-3EEC-4FED-AE92-18C4F5B3645F@lrde.epita.fr>
[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]
On Mon, Nov 26, 2007 at 21:11:41 +0100, Benoit Sigoure wrote:
> On Nov 26, 2007, at 8:27 PM, Jan Hudec wrote:
>
>> On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>> If you would write git from scratch now, from the beginning, without
>>>> concerns for backwards compatibility, what would you change, or what
>>>> would you want to have changed?
>>>
>>> Get rid of plumbing at the command line level. It is confusing to
>>
>> No, please. It's extremely useful. It should be a bit more hidden, but
>> it's
>> a big advantage of git that the plumbing is available.
>>
>>> users, and command line arguments, exec calls and I/O streams are not
>>> efficient and reasonably typed mechanisms for the kind of operations
>>> done in plumbing. Instead using a good extensible portable scripting
>>> language (I consider Lua quite suitable in that regard, but it is
>>> conceivable that something with a native list type supporting easy
>>> sorts, merges and selections could be more efficient) and implementing
>>> plumbing in that or in C would have been preferable for creating the
>>> porcelain.
>>
>> POSIX shell is really the best extensible portable scripting language
>> available for the job. Because the whipuptitude is the most important
>> property and shell is simply best at one-liners. And since you use it
>> for regular work (running editor, compiler, git porcelain), it is the
>> obvious choice for whiping up a short function.
>
> Perl seems pretty portable. If we had a decent, complete libgit, it would
> be easy to create bindings for various languages and script Git in other
> languages than Shell script.
Perl might be good for the lower level stuff (and is indeed used for that in
git a lot), but most useful tools on top of git gather few bigish bits
(contents of whole files and such) and pass them to some application. And
this is what shell is really good at.
So yes, more direct interfaces for various languages would certainly be good,
but it would never be a full replacement for the process interface. It is
most generic and for many hacks the easiest thing to use.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-26 20:40 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David Kastrup, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261511240.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
>> Nicolas Pitre <nico@cam.org> writes:
>>
> This is a mailing list and not a news group. I don't care if you use a
> newsgroup gateway if it isn't broken. As it is, gmane is broken as far
> as I'm concerned.
>
> So please complain to gmane or change your setup.
Don't blame gmane, please. I picked this message up in gmane and I am
responding to you in my newsreader.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-11-26 20:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261511240.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 26 Nov 2007, David Kastrup wrote:
>
>> In fact, for articles sent through Usenet servers, it is generally
>> considered an _annoyance_ to include unannounced "courtesy copies"
>> since replies to them will not usually reach the list and will
>> require redoing.
>
> This is a mailing list and not a news group. I don't care if you use
> a newsgroup gateway if it isn't broken. As it is, gmane is broken as
> far as I'm concerned.
A gateway should not be sending to anything but the mailing list
address. It is not a mail multiplicator.
> So please complain to gmane or change your setup.
I already explained: the git mailing list is set up in a manner that
will block mail from some accounts of mine without notice or error
report.
If there is general consensus on the list that news gateways are not
compatible with the mailing list policies, please report this to gmane,
and gmane will switch the list off-line.
I have no idea why anybody would think this an improvement, but given
the amount of flak I already got for daring to use gmane, it will
probably improve the atmosphere on the list if people like me are locked
out completely from participation rather than their usage of gmane be
lambasted time and again.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Wincent Colaiuta @ 2007-11-26 20:45 UTC (permalink / raw)
To: Jan Hudec; +Cc: David Kastrup, Nicolas Pitre, Jakub Narebski, git
In-Reply-To: <20071126195750.GD25784@efreet.light.src>
El 26/11/2007, a las 20:57, Jan Hudec escribió:
> The availability of plumbing is really big part of a reason why git
> is so
> good and has so many scripts and tool built on top of it.
Yes, the plumbing is really lovely when it comes time to whipping
together a quick tool for a special task; much nicer than writing a
plugin.
For the benefit of newcomers, I just wish the plumbing was kept a
little bit out of sight. You know, porcelain in /usr/bin and plumbing
in /usr/libexec or other such place.
It's fine once you've learnt your workflows and know the 10 or 15 Git
tools that you'll be using day-to-day; but for people who are just
starting off this can be a little bit intimidating:
$ git-<tab>
Display all 146 possibilities? (y or n)
Cheers,
Wincent
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jon Smirl @ 2007-11-26 20:48 UTC (permalink / raw)
To: Michael Poole; +Cc: Jan Hudec, David Kastrup, Benoit Sigoure, Andy Parkins, git
In-Reply-To: <87oddgzr3c.fsf@graviton.dyn.troilus.org>
On 11/26/07, Michael Poole <mdpoole@troilus.org> wrote:
> Jan Hudec writes:
>
> > On Mon, Nov 26, 2007 at 14:50:35 -0500, Michael Poole wrote:
> >> Jan Hudec writes:
> >>
> >> > The basic pull/push actions are:
> >> >
> >> > git pull: Bring the remote ref value here.
> >> > git push: Put the local ref value there.
> >> >
> >> > Are those not oposites?
> >> >
> >> > Than each command has it's different features on top of this -- pull merges
> >> > and push can push multiple refs -- but in the basic operation they are
> >> > oposites.
> >>
> >> I think that is in absolute agreement with David: Ducks swim on the
> >> surface of the water and lobsters swim underneath. Why consider the
> >> different features on top of where they swim?
> >>
> >> The thing about git-pull that surprises so many users is the merge.
> >> There's a separate command to do that step, and git-pull had a fairly
> >> good excuse to do the merge before git's 1.5.x remote system was in
> >> place, but now the only really defensible reason for its behavior is
> >> history.
> >
> > When I first looked at hg -- and that was long before I looked at git --
> > I was surprised that their pull did NOT merge and you had to do a separate
> > step. Partly because doing those two steps is quite common.
>
> Frequency of use is a good argument for having one command that does
> both. It is not a good argument that "fetch, then merge" should be
> called "pull" or is the opposite of "push".
I'm starting to think that things oriented around the default names of
master and origin needs rethinking. Everything should use explicitly
named remotes. You could always do something like set a default remote
repository, but that is different than using the magic name 'origin'.
--
Jon Smirl
jonsmirl@gmail.com
^ 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