* 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
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-26 20:55 UTC (permalink / raw)
To: Dana How; +Cc: Jakub Narebski, git
In-Reply-To: <56b7f5510711261217h56214321xb7acd9851b677dd6@mail.gmail.com>
On Mon, 26 Nov 2007, Dana How wrote:
> 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.
Sure, but let's not go overboard either.
> > > (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?
Exactly.
> Re-using (part of) the pack format
> in a blob (or maybe only some blobs) seems like less code change.
Don't know what you mean exactly here, but what I mean is to do
something as simple as:
pretend_sha1_file(...);
add_object_entry(...);
write_pack_file();
when the buffer to make a blob from is larger than a configured
treshold.
> > > 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.
Right. Only the first 16 bytes or so need to be uncompressed.
> > > 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.
Oh, you're right. Somehow I didn't count the needed decompression.
> 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.
... which my suggestion should provide with a minimum of changes, maybe
less than 10 lines of code.
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jan Hudec @ 2007-11-26 21:00 UTC (permalink / raw)
To: David Kastrup; +Cc: Nicolas Pitre, Jakub Narebski, git
In-Reply-To: <85prxwzqvn.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]
On Mon, Nov 26, 2007 at 21:35:56 +0100, David Kastrup wrote:
> 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.
But scripting in the first place means *SHELL* scripting. Or you normally use
Lua command line for your daily work?
> 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.
For myself I would say I don't think C is an appropriate tool for the job. It
is nice when you need to optimize things to the last instruction, but for my
taste it's unwieldy for the high-level stuff.
> 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.
Well, the builtins *do* use the plumbing. They just use the C functions
without using streams and forks. Isn't that what you wanted?
But the key reason for keeping the plumbing around is prototyping and
especially tailoring. Junio has many scripts (you can look at them in the
todo branch in git repo) to support his particular workflow and plumbing is
useful there. And shell is really the right tool for such things.
> I may have a big mouth, but swallowing all of this at once is beyond me.
--
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: Nicolas Pitre @ 2007-11-26 21:09 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <85hcj8zqfm.fsf@lola.goethe.zz>
On Mon, 26 Nov 2007, David Kastrup wrote:
> 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.
>
> A gateway should not be sending to anything but the mailing list
> address. It is not a mail multiplicator.
Then don't use it.
Yet Junio just replied to my mail, apparently using his news reader, and
I was directly addressed.
> > 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.
And why should _I_ care? This is _your_ problem for you to investigate.
> 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.
Look, it is you the offender here with your broken setup to interact
with this mailing list. So I'm complaining to _you_. Please cope with
it.
> 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.
Please figure out an alternative to gmane on your own, or ask those who
apparently get it to work properly. I'm sure you're bright enough to
find a way.
Nicolas
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-26 21:14 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David Kastrup, git
In-Reply-To: <alpine.LFD.0.99999.0711261511240.9605@xanadu.home>
Nicolas Pitre wrote:
> 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? ]
It is about proper _newsreader_ setup, in fact...
>> 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.
My responding [sometimes] only to list is combination of several
issues.
First, newsreader I use, namely KNode 0.10.2 in Kontact 1.2.3 from
KDE 3.5.3 does not make it easy. By default it replies only to list
unless Mail-Reply-To header is used (which shouldn't IIRC). I have
to click reply by e-mail button to send reply via email... and it
adds only last author, from From header. The rest I have to add by
hand.
Second, something is rotten^W broken between GMane and VGER; if I add
git email address to the list of addresses to send to, VGER rejects and
refuses to send to git mailing list. I have to send also to newsgroup
(gmane.comp.version-control.git) to send to all git mailing list. Now
it looks like two mails are actually send: one to CC'ed addresses, one
to git mailing list, and sometimes people when replying me forget to
reply also to git mailing list.
So third, when I don't think I have something significant to contribute,
and I don't necessary expect answer, I send email only to git mailing
list (news message only to GMane newsgroup coupled with git mailing
list, actually).
Sure, one of solutions would be for me to change newsreader, for example
to Gnus (as people using Gnus doesn't seem to have the same problem
I have), but I think you do know that it is not easy to change habits.
[cut]
Nevertheless, mails are sent to git mailing list, so they should go
to you too.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-11-26 21:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261601240.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Please figure out an alternative to gmane on your own, or ask those
> who apparently get it to work properly. I'm sure you're bright enough
> to find a way.
Without so much as a bounce message or delivery report, there is nothing
to apply one's brightness to.
Since the git mailing list is the only mailing list that censors my work
account in that manner, it is obviously set up in a way different from
most other mailing lists.
Not being a list moderator and not getting any bounce notification,
there is nothing I can use for figuring out what makes the git mailing
list different from others.
And the gratuitous hostility easily evoked towards anybody experiencing
problems with either the list or other aspects concerning git is really
something I have not experienced in any other developer circle.
And I am quite an oldtimer concerning both mailing lists and Usenet.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] Replace misleading message during interactive rebasing
From: Wincent Colaiuta @ 2007-11-26 21:18 UTC (permalink / raw)
To: git
Cc: gitster, tsuna, j.sixt, Johannes.Schindelin, mcostalba,
Wincent Colaiuta
git-rebase--interactive uses git-cherry-pick under the covers to reorder
commits, which in turn means that in the event of a conflict a message
will be shown advising the user to commit the results and use the -c
switch to retain authorship after fixing the conflict.
The message is misleading because what the user really needs to do is
run "git rebase --continue"; the committing is handled by git-rebase
and the authorship of the commit message is retained automatically.
We solve this problem by using an environment variable to communicate
to git-cherry-pick that rebasing is underway and replace the misleading
error message with a more helpful one.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
This applies on top of "master".
The question of whether the environment variable should have a leading
underscore came up on the mailing list. I don't really care at all either
way, I'd just like to see the misleading message go away. I'll leave it
up to others to decide.
Another thing to decide is whether the help text should be more than
just "run 'git rebase --continue'", but should mention
"git rebase --abort" as well. Junio, please feel free to modify the
patch if you think it would be appropriate.
builtin-revert.c | 8 +++++---
git-rebase--interactive.sh | 2 ++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index a0586f9..5a57574 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -229,7 +229,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
unsigned char head[20];
struct commit *base, *next, *parent;
int i;
- char *oneline, *reencoded_message = NULL;
+ char *oneline, *reencoded_message = NULL, *help_message;
const char *message, *encoding;
const char *defmsg = xstrdup(git_path("MERGE_MSG"));
@@ -352,11 +352,13 @@ static int revert_or_cherry_pick(int argc, const char **argv)
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
die ("Error wrapping up %s", defmsg);
+ help_message = getenv("_GIT_CHERRY_PICK_HELP");
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
"mark the corrected paths with 'git add <paths>' "
- "and commit the result.\n", me);
- if (action == CHERRY_PICK) {
+ "and %s.\n", me,
+ help_message ? help_message : "commit the result");
+ if (action == CHERRY_PICK && !help_message) {
fprintf(stderr, "When commiting, use the option "
"'-c %s' to retain authorship and message.\n",
find_unique_abbrev(commit->object.sha1,
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bf44b6a..e5f9810 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -117,6 +117,7 @@ pick_one () {
sha1=$(git rev-parse --short $sha1)
output warn Fast forward to $sha1
else
+ export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
output git cherry-pick "$@"
fi
}
@@ -187,6 +188,7 @@ pick_one_preserving_merges () {
fi
;;
*)
+ export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
output git cherry-pick "$@" ||
die_with_patch $sha1 "Could not pick $sha1"
;;
--
1.5.3.6.952.g84ef
^ permalink raw reply related
* Re: If you would write git from scratch now, what would you change?
From: Junio C Hamano @ 2007-11-26 21:24 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Jan Hudec, David Kastrup, Nicolas Pitre, Jakub Narebski, git
In-Reply-To: <AA5ECB69-3F77-483E-AD19-04A5515779B3@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> 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)
I'd agree to that but I've always considered this an issue for distros.
We've supported an ability for them to specify a gitexecdir separate
from /usr/bin in our Makefile for almost two years.
The tab completion for bash and zsh would also help you here, but I see
there are quite a few commands that should not be there, and it's time
to clean it up.
$ git <tab>
add fetch push
am filter-branch rebase
annotate format-patch rebase--interactive
apply fsck relink
archive gc remote
bisect get-tar-commit-id repack
blame grep request-pull
branch gui reset
bundle imap-send resolve
checkout init revert
checkout-index instaweb rm
cherry less send-email
cherry-pick lg shortlog
citool log show
clean lost-found show-branch
clone ls-files show-ref
co ls-remote stash
commit ls-tree status
config merge submodule
convert-objects mergetool svnimport
count-objects mv tag
describe name-rev var
diff pickaxe verify-pack
diff-stages pull whatchanged
Perhaps this list can be a starting point...
contrib/completion/git-completion.bash | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index cad842a..1bba68b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -359,6 +359,15 @@ __git_commands ()
upload-pack) : plumbing;;
write-tree) : plumbing;;
verify-tag) : plumbing;;
+ annotate) : use blame;;
+ checkout-index) : plumbing;;
+ diff-stages) : plumbing;;
+ get-tar-commit-id) : plumbing;;
+ lost-found) : deprecated;;
+ rebase--interactive) : plumbing;;
+ relink) : obsolete;;
+ whatchanged) : plumbing;;
+ verify-pack) : plumbing;;
*) echo $i;;
esac
done
^ permalink raw reply related
* Re: If you would write git from scratch now, what would you change?
From: Johannes Schindelin @ 2007-11-26 21:27 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261417580.9605@xanadu.home>
Hi,
On Mon, 26 Nov 2007, Nicolas Pitre wrote:
> 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.
I agree, but that's not even the complete truth. Git would be not even
half as useful as it is without its scriptability.
So it is not only convenience, but very much a reason that git development
is so fast. That, and that more people than elsewhere let code talk.
Which is also much easier when you have a scriptable system.
Ciao,
Dscho
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-26 21:28 UTC (permalink / raw)
To: David Kastrup; +Cc: Jan Hudec, Jakub Narebski, git
In-Reply-To: <85prxwzqvn.fsf@lola.goethe.zz>
On Mon, 26 Nov 2007, David Kastrup wrote:
> 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.
You're mixing two orthogonal issues, namely: 1) the scripting language,
and 2) the too large number of Git command accessible through your
default path.
#1 is a non issue really. We don't want to lock plumbing to any
particular scripting language, and the current interface is the most
universal one in that regard.
#2 can be solved through a single multiplexer such as 'git low-level'.
That 'git low-level foo' may just look up git-foo in some libexec
directory, and only 'git-low-level' need to be in the path instead of
all those plumbing commands.
Need only to have both forms ('git foo' and 'git low-level foo') to work
for a transition period.
Nicolas
^ permalink raw reply
* Re: Git Screencast ?
From: Scott Chacon @ 2007-11-26 21:33 UTC (permalink / raw)
To: git
In-Reply-To: <d411cc4a0711211603o525a25c4i3e04d0319e68204f@mail.gmail.com>
I've created a screencast on using Git to manage and deploy Rails
applications. It's not purely about Git - goes into some Rails and
Capistrano usage, but there is a good amount of practical git workflow
- pushing, pulling, branching, etc. It's free, too. You can
watch/download it here:
http://jointheconversation.org/railsgit
Also, if you're in the Bay Area, we're hosting a Peepcode and Pizza
party on Git - where we'll show that git peepcode episode and have
some git related presentations. You're welcome to come to that to
learn whatever you need, if you can.
http://ruby.meetup.com/123
Lastly, if you're a rubyist, I've written pretty comprehensive ruby
bindings to git that might be helpful because it's a bit more object
oriented approach to using git - the examples might help.
http://jointheconversation.org/rubygit
I'm also working on a new screencast on Git that's more visual
(example-wise) than most of the stuff I've seen, so I'll be happy to
email that to you when it's done.
Let me know if any of that is helpful.
> On Nov 21, 2007 2:36 PM, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>
> > >>>>> "Michael" == Michael Donaghy <mike@mikedonaghy.org> writes:
> >
> > Michael> I am a new user of git and SCMs in general , I have learned a lot
> > Michael> from the docs , irc and just using it , but there are just some
> > Michael> concepts that hare hard to grasp , I am a very visual persion
> > Michael> (probably like a lot of you :) ) , is there a screencast of git
> > Michael> somewhere (for free) that can demonstrate some of the advanced
> > Michael> features of git... (Also...I have seen both Randal (Schwartz) and
> > Michael> Linus' (you better know his last name) presentations at google on git
> > Michael> , in which they explain the ideas behind git more than the actual
> > Michael> usage,
> >
> > Having been involved in that screencast that you reference, I'm curious
> > about what you think you're missing in order to use git. The feedback
> > will help me produce better presentations.
> >
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-26 21:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nicolas Pitre, git
In-Reply-To: <200711262214.54291.jnareb@gmail.com>
Hi,
On Mon, 26 Nov 2007, Jakub Narebski wrote:
> Nicolas Pitre wrote:
> > 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? ]
>
> Nevertheless, mails are sent to git mailing list, so they should go to
> you too.
It was already explained (not often enough?) that some people are
extremely busy, such as Nicolas.
Therefore, they have to prioritise.
If you choose to be ignored, that's fine by me ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-26 21:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711262124411.27959@racer.site>
On Mon, 26 Nov 2007, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 26 Nov 2007, Nicolas Pitre wrote:
>
> > 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.
>
> I agree, but that's not even the complete truth. Git would be not even
> half as useful as it is without its scriptability.
Sure, but this is missing the point.
The issue at hand is about the fact that way too many Git commands are
to be found in the default command path. Diverging on whether or not
plumbing is useful is the wrong question.
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Johannes Schindelin @ 2007-11-26 21:40 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261635570.9605@xanadu.home>
Hi,
On Mon, 26 Nov 2007, Nicolas Pitre wrote:
> On Mon, 26 Nov 2007, Johannes Schindelin wrote:
>
> > I agree, but that's not even the complete truth. Git would be not
> > even half as useful as it is without its scriptability.
>
> Sure, but this is missing the point.
>
> The issue at hand is about the fact that way too many Git commands are
> to be found in the default command path. Diverging on whether or not
> plumbing is useful is the wrong question.
Ah, thanks. I use a spam filter here, so I did not get the complete
context.
Sorry,
Dscho
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-26 21:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Wincent Colaiuta, Jan Hudec, David Kastrup, Jakub Narebski, git
In-Reply-To: <7vhcj8g0op.fsf@gitster.siamese.dyndns.org>
On Mon, 26 Nov 2007, Junio C Hamano wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>
> > 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)
>
> I'd agree to that but I've always considered this an issue for distros.
> We've supported an ability for them to specify a gitexecdir separate
> from /usr/bin in our Makefile for almost two years.
Would probably be a good thing to start enforcing that by default. It's
easier to follow such policies when they're coordinated from the project
origin.
Nicolas
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-26 21:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711262135430.27959@racer.site>
On Mon, 26 Nov 2007, Johannes Schindelin wrote:
> On Mon, 26 Nov 2007, Jakub Narebski wrote:
>
> > Nevertheless, mails are sent to git mailing list, so they should go to
> > you too.
>
> It was already explained (not often enough?) that some people are
> extremely busy, such as Nicolas.
>
> Therefore, they have to prioritise.
>
> If you choose to be ignored, that's fine by me ;-)
I hate when I miss on followups to my own posts though.
That is the real issue.
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Junio C Hamano @ 2007-11-26 21:47 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Wincent Colaiuta, Jan Hudec, David Kastrup, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261631170.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 26 Nov 2007, Junio C Hamano wrote:
>
>> Wincent Colaiuta <win@wincent.com> writes:
>>
>> > 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)
>>
>> I'd agree to that but I've always considered this an issue for distros.
>> We've supported an ability for them to specify a gitexecdir separate
>> from /usr/bin in our Makefile for almost two years.
>
> Would probably be a good thing to start enforcing that by default. It's
> easier to follow such policies when they're coordinated from the project
> origin.
Not really. The project origin ships the Makefile to install under
$HOME, but I do not see any distros following that.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-26 22:02 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <85sl2sya55.fsf@lola.goethe.zz>
On Mon, 26 Nov 2007, David Kastrup wrote:
> Without so much as a bounce message or delivery report, there is nothing
> to apply one's brightness to.
Maybe you could try firing up your web browser and directing it at
http://vger.kernel.org, just in case there might be a web page set up
there with some clues. Hey, there is actually a web page there.
In particular, there is a link there that reads as "Email delivery
testing tool: mxverify". Did you try it?
There is another link with "TABOO in the lists". Maybe you might find
something there?
Nicolas
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Dana How @ 2007-11-26 22:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git, danahow
In-Reply-To: <alpine.LFD.0.99999.0711261529080.9605@xanadu.home>
On Nov 26, 2007 12:55 PM, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 26 Nov 2007, Dana How wrote:
> > On Nov 26, 2007 11:52 AM, Nicolas Pitre <nico@cam.org> wrote:
> > > On Mon, 26 Nov 2007, Dana How wrote:
> > > 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?
> Exactly.
I will think about your suggestion
(and the number of packs that might result),
but I confess I am surprised by it.
When I proposed automatically extracting large blobs from source
packs when creating a new pack under a blob size limit while
pack-objects was running, you objected on the grounds that
pack-objects only creates packs and should not create blobs
(this proposal had other problems too, but this is the one you didn't like).
Now it's OK for git-add to sometimes create packs instead of blobs?
I would not have predicted that!
;-)
--
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: Nicolas Pitre @ 2007-11-26 22:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Wincent Colaiuta, Jan Hudec, David Kastrup, Jakub Narebski, git
In-Reply-To: <7v3ausfzmh.fsf@gitster.siamese.dyndns.org>
On Mon, 26 Nov 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Mon, 26 Nov 2007, Junio C Hamano wrote:
> >
> >> Wincent Colaiuta <win@wincent.com> writes:
> >>
> >> > 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)
> >>
> >> I'd agree to that but I've always considered this an issue for distros.
> >> We've supported an ability for them to specify a gitexecdir separate
> >> from /usr/bin in our Makefile for almost two years.
> >
> > Would probably be a good thing to start enforcing that by default. It's
> > easier to follow such policies when they're coordinated from the project
> > origin.
>
> Not really. The project origin ships the Makefile to install under
> $HOME, but I do not see any distros following that.
What about the default RPM spec file?
Nicolas
^ permalink raw reply
* [PATCH] Use --no-color option on git log commands.
From: Pascal Obry @ 2007-11-26 22:04 UTC (permalink / raw)
To: git list
When colors are activated on the repository the git log output
will contain control characters to set/reset the colors. This
makes list_stash() fails as the sed regular expression does not
match the color control characters. Also use --no-color when
computing the head on create_stash() procedure.
---
git-stash.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 534eb16..cde9767 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -37,7 +37,7 @@ create_stash () {
# state of the base commit
if b_commit=$(git rev-parse --verify HEAD)
then
- head=$(git log --abbrev-commit --pretty=oneline -n 1 HEAD)
+ head=$(git log --no-color --abbrev-commit
--pretty=oneline -n 1 HEAD)
else
die "You do not have the initial commit yet"
fi
@@ -108,7 +108,7 @@ have_stash () {
list_stash () {
have_stash || return 0
- git log --pretty=oneline -g "$@" $ref_stash |
+ git log --no-color --pretty=oneline -g "$@" $ref_stash |
sed -n -e 's/^[.0-9a-f]* refs\///p'
}
--
1.5.3.6.959.g1ab5
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply related
* Re: [PATCH] Use --no-color option on git log commands.
From: Junio C Hamano @ 2007-11-26 22:30 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <474B42EC.1000408@wanadoo.fr>
Pascal Obry <pascal.obry@wanadoo.fr> writes:
> When colors are activated on the repository the git log output
> will contain control characters to set/reset the colors.
The patch is good as belt-and-suspender, thanks.
But I suspect that we should make 'true' to mean 'auto' someday in
git_config_colorbool(). Crazy people can set 'always' if they really
wanted to, but most normal people would not want color unless the output
goes to the terminal, I would think.
Something like this, perhaps...
---
color.c | 25 ++++++++++++-------------
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/color.c b/color.c
index 09d82ee..060d3cf 100644
--- a/color.c
+++ b/color.c
@@ -118,21 +118,24 @@ bad:
int git_config_colorbool(const char *var, const char *value)
{
- if (!value)
- return 1;
- if (!strcasecmp(value, "auto")) {
- if (isatty(1) || (pager_in_use && pager_use_color)) {
- char *term = getenv("TERM");
- if (term && strcmp(term, "dumb"))
- return 1;
- }
- return 0;
- }
- if (!strcasecmp(value, "never"))
- return 0;
- if (!strcasecmp(value, "always"))
- return 1;
- return git_config_bool(var, value);
+ if (value) {
+ if (!strcasecmp(value, "never"))
+ return 0;
+ if (!strcasecmp(value, "always"))
+ return 1;
+ if (!strcasecmp(value, "auto"))
+ goto auto;
+ }
+ if (!git_config_bool(var, value))
+ return 0;
+auto:
+ /* any normal truth value defaults to 'auto' */
+ if (isatty(1) || (pager_in_use && pager_use_color)) {
+ char *term = getenv("TERM");
+ if (term && strcmp(term, "dumb"))
+ return 1;
+ }
+ return 0;
}
static int color_vprintf(const char *color, const char *fmt,
^ permalink raw reply related
* Re: If you would write git from scratch now, what would you change?
From: Nicolas Pitre @ 2007-11-26 22:22 UTC (permalink / raw)
To: Dana How; +Cc: Jakub Narebski, git
In-Reply-To: <56b7f5510711261402s35b77879xdcb2492ea14a1791@mail.gmail.com>
On Mon, 26 Nov 2007, Dana How wrote:
> On Nov 26, 2007 12:55 PM, Nicolas Pitre <nico@cam.org> wrote:
> > On Mon, 26 Nov 2007, Dana How wrote:
> > > On Nov 26, 2007 11:52 AM, Nicolas Pitre <nico@cam.org> wrote:
> > > > On Mon, 26 Nov 2007, Dana How wrote:
> > > > 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?
> > Exactly.
> I will think about your suggestion
> (and the number of packs that might result),
> but I confess I am surprised by it.
>
> When I proposed automatically extracting large blobs from source
> packs when creating a new pack under a blob size limit while
> pack-objects was running, you objected on the grounds that
> pack-objects only creates packs and should not create blobs
> (this proposal had other problems too, but this is the one you didn't like).
>
> Now it's OK for git-add to sometimes create packs instead of blobs?
> I would not have predicted that!
Going back to loose objects from packs is indeed something I object to
if it becomes part of a work flow. Objects should move from the loose
space towards the packed space and not the other way around. Sure there
is fetch.unpackLimit, but with the auto-repack recently added to Git
this variable could probably be set even lower.
But having a pack created for huge blobs up front has many advantages,
the most obvious is the fact that later repack can combine and/or send
those single-blob packs with almost no cost.
Loose objects are meant to be blazingly fast to create. Once repacked
they have no advantage being loose again. Obviously when your blob is
huge you won't benefit much from a loose object.
Nicolas
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-11-26 23:05 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261649000.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 26 Nov 2007, David Kastrup wrote:
>
>> Without so much as a bounce message or delivery report, there is nothing
>> to apply one's brightness to.
>
> Maybe you could try firing up your web browser and directing it at
> http://vger.kernel.org, just in case there might be a web page set up
> there with some clues. Hey, there is actually a web page there.
I really _love_ how the default response on this list for any problem is
to treat one as an idiot and openly show one's contempt. The
information about subscribing to the mailing list can be found at the
Git home page at <URL:http://git.or.cz/#community>. It does not mention
anything like a mailing list home page. Only the archives are
mentioned, and those contain no pointer whatsoever. It does remind me
of the late Douglas Adams' Hitchhiker's guide to the galaxy:
`...You hadn't exactly gone out of your way to call attention to
them had you? I mean like actually telling anyone or anything.'
`But the plans were on display...'
`On display? I eventually had to go down to the cellar to find
them.'
`That's the display department.'
`With a torch.'
`Ah, well the lights had probably gone.'
`So had the stairs.'
`But look you found the notice didn't you?'
`Yes,' said Arthur, `yes I did. It was on display in the bottom of a
locked filing cabinet stuck in a disused lavatory with a sign on the
door saying "Beware of The Leopard".'
Anyway, with your pointer I might be able to work through the stuff and
figure out what makes vger so unique here as a mailing list host.
On the other hand: why bother participating in a community that turns
openly hostile whenever one experiences problems? Where is the fun in
that? That one will at one point of time be in the situation to lambast
others for their shortcomings, and feel that one is entirely in-style
doing so here?
Is it really impossible to proffer any information without a denigrating
sneer?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] Make Git accept absolute path names for files within the work tree
From: Robin Rosenberg @ 2007-11-26 23:18 UTC (permalink / raw)
To: gitster; +Cc: git, Robin Rosenberg
This patch makes it possible to drag files and directories from
a graphical browser and drop them onto a shell and feed them
to common git operations without editing away the path to the
root of the work tree.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
setup.c | 16 ++++++++++++++
t/t3904-abspatharg.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 69 insertions(+), 0 deletions(-)
create mode 100755 t/t3904-abspatharg.sh
Was it this simple?
diff --git a/setup.c b/setup.c
index 43cd3f9..9b3a9ff 100644
--- a/setup.c
+++ b/setup.c
@@ -6,6 +6,22 @@ static int inside_work_tree = -1;
const char *prefix_path(const char *prefix, int len, const char *path)
{
+ if (is_absolute_path(path)) {
+ const char *work_tree = get_git_work_tree();
+ int n = strlen(work_tree);
+ if (!strncmp(path, work_tree, n) && (path[n] == '/' || !path[n])) {
+ if (path[n])
+ path += 1;
+ path += n;
+ if (prefix && !strncmp(path, prefix, len - 1)) {
+ if (path[len - 1] == '/')
+ path += len;
+ else
+ if (!path[len - 1])
+ path += len - 1;
+ }
+ }
+ }
const char *orig = path;
for (;;) {
char c;
diff --git a/t/t3904-abspatharg.sh b/t/t3904-abspatharg.sh
new file mode 100755
index 0000000..aa47602
--- /dev/null
+++ b/t/t3904-abspatharg.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+#
+# Copyright (C) 2007 Robin Rosenberg
+#
+
+test_description='Test absolute filename arguments to various git
+commands. Absolute arguments pointing to a location within the git
+work tree should behave the same as relative arguments. '
+
+. ./test-lib.sh
+
+test_expect_success 'add files using absolute path names' '
+echo a >afile &&
+echo b >bfile &&
+git-add afile &&
+git-add $(pwd)/bfile &&
+test "afile bfile" = "$(echo $(git ls-files))"
+mkdir x &&
+cd x &&
+echo c >cfile &&
+echo d >dfile &&
+git-add cfile &&
+git-add $(pwd) &&
+cd .. &&
+test "afile bfile x/cfile x/dfile" = "$(echo $(git ls-files))" &&
+test "$(echo $(git ls-files x))" = "$(echo $(git ls-files $(pwd)/x))"
+'
+
+test_expect_success 'commit using absolute path names' '
+git commit -m "foo" &&
+echo aa >>bfile &&
+git commit -m "bb" $(pwd)/bfile
+'
+
+test_expect_success 'log using absolute path names' '
+git log afile >f1.txt &&
+git log $(pwd)/afile >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_expect_success 'blame using absolute path names' '
+git blame afile >f1.txt &&
+git blame $(pwd)/afile >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_expect_success 'diff using absolute path names' '
+git diff HEAD^ -- $(pwd)/afile >f1.txt &&
+git diff HEAD^ -- afile >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_done
--
1.5.3.5.1.gb2df9
^ 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