* Re: [VOTE] git versus mercurial
From: walt @ 2008-10-28 12:31 UTC (permalink / raw)
To: git
In-Reply-To: <ge0rla$mce$1@ger.gmane.org>
walt wrote:
> No, no, I'm not the one calling for a vote. You old-timers here
> will know the name Matt Dillon, who is leading the dragonflybsd
> project (www.dragonflybsd.org).
>
> Matt is the one who is calling for the vote in his thread "Vote
> for your source control system" in the dragonfly.kernel group,
> accessible via nntp://nntp.dragonflybsd.org...
The official vote was 19 to 19, plus one for perforce and one
for svn. Matt has proposed a primary git repository and a mirror
in hg, and that's being debated now.
I've already learned a lot from following this topic in both
lists and it seems this is a topic of great interest to many,
so I'll continue reading in both places.
Thanks!
^ permalink raw reply
* Re: [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Alex Riesen @ 2008-10-28 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Mark Levedahl, spearce, dpotapov, git
In-Reply-To: <7vhc6xh010.fsf@gitster.siamese.dyndns.org>
2008/10/28 Junio C Hamano <gitster@pobox.com>:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>> Quoting Junio C Hamano <gitster@pobox.com>:
>>
>>> This is the answer to the question I asked in:
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/97986/focus=98066
>>>
>>> Perhaps we should use a separate variable as the original patch did, in:
>>>
>>> http://article.gmane.org/gmane.comp.version-control.git/97987
>>>
>>> How about doing it like this instead?
>>
>> Junio, may I ask what the status of this patch is? I see you did not write tests nor commit message --- are you waiting for others to write them?
>
> Heh, Alex's ack is good enough for me as far as the code itself is
> concerned, but I do want these "fixes" accompanied by additional tests to
> reproduce to avoid future regressions, and this being a Cygwin fix, I am
> not really the right person to write tests nor run them.
I suggest NOT writing the test for the workaround for just one platform I
personally call the most idiotic of the Microsoft's fallouts. As the
fix is located
in the code specific to that platform, it wont do any harm for anyone, whether
it works or not (even if the code in tree does not work). The Junio's fix is
definitely enough for me and, I'm very sure, for anyone still having to
deal with cygwin.
So for the Google's record: the patch to fix the --encoding option of git
format-patch broken on cygwin is in the Junio's mail, to be found, i.e.:
http://marc.info/?l=git&m=122482769817566&w=4
Nanako, as there is not many of such poor bastards left, it is not
even a problem
to keep the fix just in Git mailing list archives. There is just not
enough of a looser
base to press its development in whatever direction.
^ permalink raw reply
* Re: [PATCH 6/6] t9400, t9401: use "git cvsserver" without dash
From: Dmitry V. Levin @ 2008-10-28 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wtzvd8h.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
Hi,
On Wed, Sep 10, 2008 at 03:37:50PM -0700, Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
> > Subject: [PATCH] Install git-cvsserver in $(bindir)
> >
> > It is one of the server side programs and needs to be found on usual $PATH.
> >
> > Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> > ...
> > - $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X '$(DESTDIR_SQ)$(bindir_SQ)'
> > + $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver$X '$(DESTDIR_SQ)$(bindir_SQ)'
>
> Thanks.
>
> Will queue but without $X at the end, as I do not think we want it even on
> Windows because cvsserver is a script.
Please apply this compatibility fix (commit v1.6.0.1-308-gede4caf)
to maint as well.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] "git shell" won't work, need "git-shell"
From: Dmitry V. Levin @ 2008-10-28 11:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20080824202325.GA14930@eagain.net>
[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
Hi,
Please apply this compatibility fix (commit v1.6.0.1-90-g27a6ed4)
to maint as well.
On Sun, Aug 24, 2008 at 11:23:25PM +0300, Tommi Virtanen wrote:
> >From 8e7935231e8a91d470b3a4a2310803031ef49fc4 Mon Sep 17 00:00:00 2001
> From: Tommi Virtanen <tv@eagain.net>
> Date: Sun, 24 Aug 2008 23:20:33 +0300
> Subject: [PATCH] Install git-shell in bindir, again.
>
> /etc/passwd shell field must be something execable, you can't enter
> "/usr/bin/git shell" there. git-shell must be present as a separate
> executable, or it is useless.
>
> Signed-off-by: Tommi Virtanen <tv@eagain.net>
> ---
>
> Hi. Recent changes moved away from "git-foo" to "git foo", except for
> some commands that needed backwards compatibility. However, git-shell
> as a separate binary was removed. I hope you will reinstante git-shell
> as a publicly visible binary in bin. Here's why:
>
> The shell field in /etc/passwd is *exec*ed, not interpreted via sh -c
> or some such. For example, source of Debian's shadow, containing
> /bin/login:
>
> libmisc/shell.c:80: execle (file, arg, (char *) 0, envp);
>
> I also tested this for real, and having a
>
> test:x:1001:1001:,,,:/home/test:/usr/bin/git-shell
>
> line works, and
>
> test:x:1001:1001:,,,:/home/test:/usr/bin/git shell
>
> just makes ssh loop asking for a password, logging
>
> "User test not allowed because shell /usr/bin/git shell does not exist"
>
> So, as far as I understand, as it currently is, "git shell" is utterly
> useless for what it was meant to do. Restoring "git-shell" will fix
> it.
>
> Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 53ab4b5..24d5809 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1351,7 +1351,7 @@ install: all
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
> $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
> - $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
> + $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X '$(DESTDIR_SQ)$(bindir_SQ)'
> $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
> $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
> ifndef NO_TCLTK
> --
> 1.6.0.2.g2ebc0.dirty
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Problem with Git.pm bidi_pipe methods
From: Christian Jaeger @ 2008-10-28 9:12 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: git
In-Reply-To: <20081024001446.GE17717@plop>
Philippe Bruhat (BooK) wrote:
> Hi,
>
> To be able to call commit-tree from a Perl program, I had to use
> command_bidi_pipe() to pass the message on standard input, and get the
> new commit id on standard output. The only problem I have is that the
> method doesn't work (or at least, doesn't work like the other
> command_... methods).
Not really an answer on how to fix Git.pm, but: you may want to subclass
Git.pm and add your own methods ad interim. See the thread "[PATCH]
Git.pm: do not break inheritance" [1] about how to subclass (I see that
this patch is actually in {next,pu} already, and anyway you can use the
runtime patching approach I described there).
That approach of using subclasses has two benefits: (a) it will tend to
make your code work with various versions of Git (i.e. one without a
fixed command_bidi_pipe method), and (b) you will be much more free to
extend the code. The drawback will be of course that your inventions
won't necessarily make it back to Git.pm, but I'm tempted to think that
some innovation taking place before settling on what should make it back
to Git.pm (or, if incompatible, possibly a new Git.pm) would be worthwhile.
For an actual example in writing Git subclasses see "[ANNOUNCE] intergit
repository-linking tool (early release)" [2].
Christian.
[1] http://article.gmane.org/gmane.comp.version-control.git/98568
[2] http://article.gmane.org/gmane.comp.version-control.git/99197
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-28 8:12 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Peter Harris, git
In-Reply-To: <49061C6D.2070407@xiplink.com>
Marc Branchaud venit, vidit, dixit 27.10.2008 20:54:
> Michael J Gruber wrote:
>> Downside is that .gitremotes is tracked would show up as a file in the
>> repo, but I can't come up with a better way which is as simple as the
>> above. .gitremotes could be stored in a specially named branch, though.
>
> That downside is a bit disappointing. I might as well just make "git
> remote export" simply generate a script of "git remote add" commands
> based on the contents of .git/config, and check that script in. Then I
> could run the script in a clone to recreate the origin's remotes.
Yes, if you feel okay about running a script repeatedly which may change
due to being versioned; rather than running a script/command which uses
versioned input.
> It also seems awkward to have an export step in the origin repository.
> I don't really see a need for an export step (except as an artifact of
> the above implementation).
I had the impression that you want to configure as much as possible on
the "central", and have clones follow automatically. It's very likely
that you want your clones to see only a subset of central's remotes.
Both (individually) imply that there has to be a step on central which
determines which (if any) central remotes appear in clones automatically.
> It seems to me that this would be more natural if our hypothetical "git
> remote import <X>" could just grab the remotes from repository <X> (or
> the origin, if <X> is unspecified). I assume that would involve
> lower-level changes than what you described, but to me it seems like the
> more usable approach. (But then I know nothing of Git's internals, so
> maybe this kind of change would be too much work?)
Feel free to hack the protocol and remote commands... Implementing
anything which exposes "server's" .git/config on the client without
interaction on the server side will most probably be rejected, though.
My suggestions were meant to be a minimal effort attempt within and
following (see submodules) current infrastructure. I guess now it's up
to you to pick the approach you deem most appropriate in your scenario
and follow through with it.
Michael
^ permalink raw reply
* Re: Terminology question: "tracking" branches
From: Björn Steinbrink @ 2008-10-28 8:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Marc Branchaud, Peter Harris, git, Junio C Hamano
In-Reply-To: <20081027162840.GK3612@atjola.homenet>
On 2008.10.27 17:28:40 +0100, Björn Steinbrink wrote:
> On 2008.10.23 10:07:07 +0200, Michael J Gruber wrote:
> > That leaves open:
> >
> > - What does "remote branch" mean, if it means anything at all? It could
> > be used for a branch in a remote repository, i.e. the other side of
> > fetch/push refspec (remote branch:tracking branch).
>
> I prefer to say "the branch on the remote" there, but that's just to
> avoid confusion with "remote tracking branch".
So I just happened to use "git remote show origin" and that uses "remote
branch" as you described it:
* remote origin
URL: git://git.kernel.org/pub/scm/git/git.git
Remote branch merged with 'git pull' while on branch master
master
Tracked remote branches
html
maint
...
JFYI
Björn
^ permalink raw reply
* alternate log --follow idea
From: Jeff King @ 2008-10-28 6:44 UTC (permalink / raw)
To: git
At the GitTogether this morning, I mentioned an alternate idea for
looking at the history of a file that moved. Currently we have:
1. git log <path>
Show the commits, in reverse chronological order, that touched any
content that at the time of touching resided at <path>.
2. git log --follow <path>
Show the commits, in reverse chronological order, for the content
currently in <path>, where we find movement of content from one path
to another by checking single commits, and say either "all of this
content moved from one path to another" or not.
3. git blame <path>
Show the current content of <path>, but with each line of content
showing the commit that introduced it.
In a repository with moving files, '1' is often insufficient or
annoying, since you get to the "root" of the file and discover that it
really came from somewhere else. In other words, you never really cared
about that path at all, but rather about the _content_ in it.
So you try '2', but that has its own drawbacks. It only works on one
file at a time, and it doesn't work on many cases, including "git log
--follow git-gui/git-gui.sh".
So you move to '3', which sort of works. It shows you the commits that
introduced the current content, but not in the log format. That is, if
you don't care about "which commit introduced this particular line" but
rather "what are the commits that created this content", it is not very
useful. You see the same commits repeated (since they often change many
lines), the commits are shown in file order rather than reverse
chronological order, and you don't get the usual nicely formatted log.
So the new idea is very simple: look at the current content, get the
list of all commits which were involved in creating that content, and
then display them as a flattened history in the usual git-log way.
The script below implements a very naive version:
-- >8 --
#!/bin/sh
dashed() {
for i in "$@"; do
case "$i" in
-*) echo $i ;;
esac
done
}
nondashed() {
for i in "$@"; do
case "$i" in
-*) ;;
*) echo $i ;;
esac
done
}
# hope we don't have spaces in our arguments
git ls-files `nondashed "$@"` |
while read file; do
git blame --porcelain "$file" |
egrep '^[0-9a-f]{40}' |
cut -d' ' -f1
done |
sort -u |
xargs git log --no-walk `dashed "$@"`
-- >8 --
You can try:
sh blame-log.sh git-gui/git-gui.sh
which should Just Work. Because it expands its arguments via ls-files,
you can also track the content of a whole directory:
sh blame-log.sh -p contrib/examples
which finds all of the commits that touched those files, even when they
were not yet in contrib (in fact, it even traces some of the lines back
to git-tag-script!).
Of course it has its downsides (aside from this horrific
implementation). For one thing, it's _way_ slower than a regular log,
especially on a large chunk of content. Some of that is in the
implementation, but mostly it is that blame takes a lot of computation.
We might be able to make things better with a specialized blame.
And as somebody (I think Steven) mentioned earlier, it only traces
content which survived to the end. So it won't mention commits which
were later eradicated, which may be useful to see.
And I'm sure there are probably other little problems, as I haven't
thought too deeply about this. But maybe it is worth adding to the
arsenal of exploration tools.
-Peff
^ permalink raw reply
* Re: problems with clone and .gitattributes
From: Jeff King @ 2008-10-28 5:50 UTC (permalink / raw)
To: Leo Razoumov; +Cc: git
In-Reply-To: <ee2a733e0810271146r5b21213eg989045e4bf42d99a@mail.gmail.com>
On Mon, Oct 27, 2008 at 02:46:41PM -0400, Leo Razoumov wrote:
> There is a little catch-22 problem here. .gitattributes are stored
> in-tree and git clone does not know about these files existence until
> it checks the tree out, by that time it is already too late to apply
> filters.
Yes, this has been brought up on the list before.
> Of course, there could be several obvious workarounds:
>
> (1) git clone can redo checkout when it finds files affected by gitattributes
>
> (2) before doing checkout "git clone" inspects tree-object and looks
> for .gitattributes files. If found it checks them out first before all
> other files. Now it can apply the attributes found as the checkout
> process progresses.
I think (2) is closer to the right solution. Though instead of changing
checkout order, I think .gitattributes should simply be able to look in
an auxiliary tree (and checkout would feed the to-be-checked-out tree to
the attribute machinery). One concern, though, is how to handle
conflicts between the tree we're moving _to_ and what's already in the
working tree. I would think that the tree we're moving to would take
precedence.
I feel like Junio may have mentioned some of these issues in a mail the
last time this subject came up, but maybe I'm mis-remembering. Try
searching the archive.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 5:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810271306230.3386@nehalem.linux-foundation.org>
On Mon, Oct 27, 2008 at 01:07:10PM -0700, Linus Torvalds wrote:
> We already support decorating commits by tags or branches that point to
> them, but especially when we are looking at multiple branches together,
> we sometimes want to see _how_ we reached a particular commit.
I think this is a cool feature, but I have a few questions/complaints:
- Does it make sense to have this _in addition_ to --decorate (since
for any commit with a --decorate field, it would likely be the same
as --source)? Should it be a different type of decorate instead,
like --decorate=source or --decorate=branch?
- Should this be triggered by the "%d" --pretty=format specifier? This
two-liner:
diff --git a/pretty.c b/pretty.c
index f6ff312..bdaad19 100644
--- a/pretty.c
+++ b/pretty.c
@@ -487,6 +487,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
const char *prefix = " (";
load_ref_decorations();
+ if (commit->util)
+ printf("%s", (char *)commit->util);
d = lookup_decoration(&name_decoration, &commit->object);
while (d) {
strbuf_addstr(sb, prefix);
works, but:
- it doesn't check revs->show_source, so is it possible that
commit->util is being used for something else?
- using '%d' automatically turns on --decorate, so you end up with
both the --source and --decorate values. More sensible semantics
would be "%d turns on --decorate, unless you have done
--decorate=<explicit format>".
Alternatively, this should just be "%b" or "%S".
- If you don't specify --all, you just get "HEAD" for everything.
Which makes sense when you consider the implementation, but I think
is probably a bit confusing for users.
> Of course, if the commit is reachable through multiple sources (which is
> common), our particular choice of "first" reachable is entirely random
> and depends on the particular path we happened to follow.
Hmm. It would be nice to keep even a simple counter to get a "distance"
from the ref and choose the one with the smallest distance (I think we
can get away without the complex rules that git-describe uses, since we
are not interested in describing the full commit, but rather finding a
"likely" branch).
However, that would require making multiple passes over the commit
graph, which might impact the startup speed.
-Peff
^ permalink raw reply related
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9
From: Junio C Hamano @ 2008-10-28 4:14 UTC (permalink / raw)
To: David Syzdek; +Cc: Junio C Hamano, git
In-Reply-To: <9a0027270810270623h4c0c34d0vcd92f61edff6da5@mail.gmail.com>
"David Syzdek" <syzdek@gmail.com> writes:
> The following should match against FreeBSD 4.x:
>
> FREEBSD_MAJOR := $(shell sh -c 'echo $(uname_R) |cut -d. -f1')
> ifeq ($(FREEBSD_MAJOR),4)
> NO_UINTMAX_T = YesPlease
> NO_STRTOUMAX = YesPlease
> endif
>
> Is the use of FREEBSD_MAJOR okay, or would another name be more appropriate?
Other parts of the Makefile seems to do something like this:
ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
^ permalink raw reply
* Re: [PATCH] Add mksnpath and git_snpath which allow to specify the output buffer
From: Junio C Hamano @ 2008-10-28 3:35 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Linus Torvalds
In-Reply-To: <20081027064537.GA4751@blimp.localdomain>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Mon, Oct 27, 2008 06:07:24 +0100:
>> Where is git_snpath() used?
>
> Nowhere yet, but it should replace git_path in every call where the
> result is not used immediately. Which, as the story with cygwin
> porting shows, can be sometimes not quite trivial (who could suspect
> lstat(2) will have application local side effects?).
>
> Maybe I should resend the patches without it, following by patches
> introducing git_snpath and replacing calls to git_path.
I took the liberty of doing the first half of just that ;-)
I also think this series of fix is maint-worthy, and splitted the last one
into two so that maint and master can be fixed independently.
^ permalink raw reply
* Re: [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Junio C Hamano @ 2008-10-28 3:27 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Alex Riesen, Mark Levedahl, spearce, dpotapov, git
In-Reply-To: <20081027192018.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> This is the answer to the question I asked in:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/97986/focus=98066
>>
>> Perhaps we should use a separate variable as the original patch did, in:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/97987
>>
>> How about doing it like this instead?
>
> Junio, may I ask what the status of this patch is? I see you did not write tests nor commit message --- are you waiting for others to write them?
Heh, Alex's ack is good enough for me as far as the code itself is
concerned, but I do want these "fixes" accompanied by additional tests to
reproduce to avoid future regressions, and this being a Cygwin fix, I am
not really the right person to write tests nor run them.
^ permalink raw reply
* Re: [RFC PATCH v2] fetch-pack: log(n)-transmission find_common()
From: Junio C Hamano @ 2008-10-28 3:24 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Thomas Rast, git
In-Reply-To: <20081027192923.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Thomas Rast <trast@student.ethz.ch>:
>
>> Replaces the existing simple history search with a more sophisticated
>> algorithm:
>>
>> 1) Walk history with exponentially increasing stride lengths; i.e.,
>> send the 1st commit, then the 2nd after that, then the 4th after
>> that, and so on.
>>
>> 2) Bisect the resulting intervals.
>
> Junio, may I ask what the status of this patch is? I see Nicolas responded and said "I gave this a quick try". Wasn't it a good enough review?
I took the "quick try" more about "first feel in performance" and not
"code review concentrating on correctness and trying to catch mistakes".
I like what the patch tries to solve, and the approach it takes to solve
it. I haven't had a chance to have a block of time for me to concentrate
on this patch to assess where it could go wrong yet.
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Junio C Hamano @ 2008-10-28 3:21 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Tuncer Ayaz, git
In-Reply-To: <20081027190816.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Tuncer Ayaz <tuncer.ayaz@gmail.com>:
>
>> After fixing clone -q I noticed that pull -q does not do what
>> it's supposed to do and implemented --quiet/--verbose by
>> adding it to builtin-merge and fixing two places in builtin-fetch.
>
> Junio, may I ask what the status of this patch is? Maybe the patch was lost in the noise? The commit log message is written very differently from existing commits in the history of git, and I am thinking that maybe that is why you did not like the whole patch? Or is it lack of any test script?
Well, perhaps you've been with us long enough to get too picky like
myself, but this was genuinely lost in the noise and my scrambling to get
back to normal. We do not typically say "I did this, I did that", but the
first paragraph in Tuncer's message is perfectly fine. I would probably
liked the second paragraph better if it were after --- lines (it is more
about the possible enhancements in other areas, and does not belong to the
commit log message for this change), but it is not a grave enough offence
to get the patch rejected.
The patch itself looks Ok; the lack of test script additions does indeed
bother me somewhat, but it is not too big a deal.
P.S. We are having fun at GitTogether'08 in the first half of this week,
so please expect slower response than usual.
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Nicolas Pitre @ 2008-10-28 1:28 UTC (permalink / raw)
To: Jakub Narebski
Cc: Brandon Casey, Arne Babenhauserheide, mercurial, SLONIK.AZ, git
In-Reply-To: <200810272137.07309.jnareb@gmail.com>
On Mon, 27 Oct 2008, Jakub Narebski wrote:
> On the other access from "smart" client (git://, ssh://, future "smart"
> HTTP server) results in creating a pack, so we cannot allow for too
> tight pack compression, or to be more exact too much CPU load taken.
Don't forget that, in those cases, the created pack for streaming is
copying chunks of data from existing packs for most objects, effectively
reusing for free the work that has previously been done to tightly
compress those packs.
Nicolas
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Miklos Vajna @ 2008-10-28 0:13 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: Jakub Narebski, git, mercurial, SLONIK.AZ
In-Reply-To: <200810272230.51683.arne_bab@web.de>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Mon, Oct 27, 2008 at 10:30:44PM +0100, Arne Babenhauserheide <arne_bab@web.de> wrote:
> Means git can provide additional commands and only has the limitation that I
> can't overwrite the basic commands, right?
Yes. And in general the API is the output of the plumbing commands, not
the API of libgit which is totally unstable.
> But we're slowly moving off topic, aside from "OK, git also has extensions -
> they are called external commands".
I think we're offtopic since the dragonfly list is not in cc. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 23:25 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: git, mercurial, SLONIK.AZ
In-Reply-To: <200810272149.13542.arne_bab@web.de>
Dnia poniedziałek 27. października 2008 21:48, Arne Babenhauserheide napisała:
> Am Montag 27 Oktober 2008 19:01:48 schrieb Jakub Narebski:
> > Besides is writing plugin in Python for Mercurial that much easier
> > than writing new command or stuff in C for Git? Well, perhaps it is,
> > as only recently there began to appear API documentation, and there
> > were created utility mini-libraries like strbuf, or string_list,
> > or parseopt.
>
> Yes, for two main reasons:
>
> 1) Writing Python is much easier and quicker than writing C, especially when
> you can just experiment with the Python interpreter (or better still: with
> ipython). No memory management hassle, no strange compiler bugs, no stray
> pointers. Just plain writing what you want to do. But if you need C speed, you
> can still include parts written in C - where you really need it. For all other
> cases you have more readable and far more compact code.
In Git you can write in C, using (underdocumented) git API, or you can
script (in shell script, in Perl, in Python, in Ruby) using git plumbing
commands which are meant for scripting (or bindings in appropriate
language).
Most new features, like git-remote tool to manage interaction with
multiple remote repositories, each of which can have multiple branches,
start as a shell or Perl script, and when they and their UI mature they
get converted into C (made into builtin). Builtinification is done not
only for performance, but also for portability (think Perl support on
MS Windows).
So in Mercurial you can write in Python, or you can write in C; in Git
you can write in any scripting language (e.g. shell script, Perl, Tcl/Tk),
or you can write in C... yes, I know it is oversimplification...
> 2) You can easily access every core function, and you can replace every
> command.
> You don't have to invent a "git foolog" command. Instead you can just adapt
> the regular log to do a foolog which people can use via "hg log".
Well, if I remember correctly if you drop git-foo in EXEC_PATH, then
you would be able to call it as "git foo". So adding commands is easy.
Git provides a few entry points which can be used to extend
functionality. They are: hooks system; gitattributes to define custom
merge, diff and clean/smudge (checkout) drivers per file (pathname);
custom merge strategies; EXTRENAL_DIFF and EXTERNAL_GREP.
I'm not sure if other messing with core functions is a good idea to
have such ability accessible.
> > The extending via plugins idea used by Mercurial, so succesfull IMHO
> > for Firefox, and I think quite successfull for ikiwiki for example, is
> > not without drawbacks, especially that there is no plugins clearinghouse,
> > and plugins are required for what is considered pretty required
> > functionality, like bisect before hg 1.0.
>
> But they can just be included in the core distibution once they become central
> enough.
Having some extensions blessed to be included with core program (like
ikiwiki with goodstuff, and similar to Git with contrib/ section)
solves some problems of relying on extensions for basic functionality.
I for example consider bisect and patch+mail workflow tools to be basic,
while patch queue management (well, patch management in general) to be
something that can be built on top of SCM, like StGit, Guilt, TopGit
for Git, or mq (Mercurial Queues) for Mercurial.
>
> It's a way of allowing people to add functionality they miss without forcing
> them to mess with core code instantly.
The problem with extensions IMVVVHO is that they don't require to
follow strict "inclusion in core" standards, which means that there
is no pressure to add them to core... which for example leads to
including bisect in core only since hg v1.0, "because it is available
as extension".
Requiring to use large amount of extensions to having required
functionality is also one of bad consequences of extension based
development, although having default set of extensions that can be
turned on via some metaextension / metapackage (like ikiwiki's
goodstuff) reduces impact of this.
Extensions / modules / plugins are good in projects with high
barriers of development, like Mozilla / Firefox, GNU Emacs, etc.
but I am not sure if it doesn't make for slower core development...
> Gits missing plugin system might just be a reason, why its usability still
> suffers from many problems: They have to do everything for everyone all the
> time, so the chances are high, that they won't do it really good for anyone
> (but the main git coders).
Well, Git doesn't have plugin system, but is easily scriptable...
And, at least according to annual Git User's Survey results (on git wiki)
many people create their custom scripts and scriplets to make their work
with SCM easy...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 21:30 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jakub Narebski, git, mercurial, SLONIK.AZ
In-Reply-To: <20081027210716.GS2273@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
Am Montag 27 Oktober 2008 22:07:16 schrieb Miklos Vajna:
> You compare Python to C here, but did you realize that in git you can
> write your git command in any language you want? Of course it's
> recommended to do it in C/shell/perl if you want to get it included in
> git.git, but that's just a decision.
I was asked explicitely about the difference of writing a Mercurial extension
and of writing some addition for git in C, so I answered that.
> IIRC the main reason git aliases can't overwrite git commands is because
> that would break scripts relying on the output of existing git commands.
> Given that I install such an extension, won't my script break?
Since that "script" will likely be an extension which will use the core
function instead of the UI command, it won't break.
Stuff which does command line parsing can naturally break when I change the
output. But it can also directly use the advanced features.
> From a user's point of view, I think external git commands and such hg
> plugins are equal. The user instally the "foo"
> extension/command/plugin/whatever and gets the "git/hg foo" command.
[snip]
> Same for git, as long as it's written in a scripting language; you
> should include git-foo in PATH then you can use git foo.
Means git can provide additional commands and only has the limitation that I
can't overwrite the basic commands, right?
But we're slowly moving off topic, aside from "OK, git also has extensions -
they are called external commands".
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Miklos Vajna @ 2008-10-27 21:07 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: Jakub Narebski, git, mercurial, SLONIK.AZ
In-Reply-To: <200810272149.13542.arne_bab@web.de>
[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]
On Mon, Oct 27, 2008 at 09:48:50PM +0100, Arne Babenhauserheide <arne_bab@web.de> wrote:
> 1) Writing Python is much easier and quicker than writing C, especially when
> you can just experiment with the Python interpreter (or better still: with
> ipython). No memory management hassle, no strange compiler bugs, no stray
> pointers. Just plain writing what you want to do. But if you need C speed, you
> can still include parts written in C - where you really need it. For all other
> cases you have more readable and far more compact code.
You compare Python to C here, but did you realize that in git you can
write your git command in any language you want? Of course it's
recommended to do it in C/shell/perl if you want to get it included in
git.git, but that's just a decision.
> 2) You can easily access every core function, and you can replace every
> command.
> You don't have to invent a "git foolog" command. Instead you can just adapt
> the regular log to do a foolog which people can use via "hg log".
IIRC the main reason git aliases can't overwrite git commands is because
that would break scripts relying on the output of existing git commands.
Given that I install such an extension, won't my script break?
> The defaults should be the most common way to use the tool, so people can
> easily learn it.
>
> Advanced stuff can be added with extensions.
From a user's point of view, I think external git commands and such hg
plugins are equal. The user instally the "foo"
extension/command/plugin/whatever and gets the "git/hg foo" command.
> And because the most used plugins are distributed with Mercurial, I can also
> activate them when I don't control the Mercurial installation - and should
> something be missing which I need, I can just download and activate a plugin
> without having to compile anything, since they are simply Python modules.
>
> Just set
> [extensions]
> foo = /blah/foo.py
>
> in ~/.hgrc and the foo plugin is active.
Same for git, as long as it's written in a scripting language; you
should include git-foo in PATH then you can use git foo.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 20:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, mercurial, SLONIK.AZ
In-Reply-To: <200810271901.48925.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4084 bytes --]
Am Montag 27 Oktober 2008 19:01:48 schrieb Jakub Narebski:
> AFAIK Git mostly follows BitKeeper UI; it is quite natural as it was
> meant as replacement for BitKeeper for Linux kernel development.
It is a great choice for an SCM intended for kernel development where everyone
knows bitkeeper, but might not be optimal for other tasks.
> Besides is writing plugin in Python for Mercurial that much easier
> than writing new command or stuff in C for Git? Well, perhaps it is,
> as only recently there began to appear API documentation, and there
> were created utility mini-libraries like strbuf, or string_list,
> or parseopt.
Yes, for two main reasons:
1) Writing Python is much easier and quicker than writing C, especially when
you can just experiment with the Python interpreter (or better still: with
ipython). No memory management hassle, no strange compiler bugs, no stray
pointers. Just plain writing what you want to do. But if you need C speed, you
can still include parts written in C - where you really need it. For all other
cases you have more readable and far more compact code.
2) You can easily access every core function, and you can replace every
command.
You don't have to invent a "git foolog" command. Instead you can just adapt
the regular log to do a foolog which people can use via "hg log".
> Also often third-party projects or stuff in contrib gets incorporated
> into git proper; sometimes stuff is moved from git core to contrib,
> if there is no maintainer however (git-svnimport, git-p4import).
> Git repository has many roots: one from git core, one with gitk
> (graphical history viewer), one from what was git mail tools, one
> with gitweb (web interface), and one with git-gui (graphical commit
> tool).
Maybe I should include the extensions in the codeswarm to have matching
repositories.
> The extending via plugins idea used by Mercurial, so succesfull IMHO
> for Firefox, and I think quite successfull for ikiwiki for example, is
> not without drawbacks, especially that there is no plugins clearinghouse,
> and plugins are required for what is considered pretty required
> functionality, like bisect before hg 1.0.
But they can just be included in the core distibution once they become central
enough.
It's a way of allowing people to add functionality they miss without forcing
them to mess with core code instantly.
> See also blog post on vcscompare: "Plugins In Version Control"
> http://vcscompare.blogspot.com/2008/06/plugins-in-version-cotnrol.html
I just read it, and it didn't convince me, because in my opinion a VCS has
certain core functions which it should provide to everyone, and other
functionality which only certain people need.
For example I normally don't need rebasing, mercurial queues, transplanting
and similar. Why should my tool include the commands by default?
The defaults should be the most common way to use the tool, so people can
easily learn it.
Advanced stuff can be added with extensions.
And because the most used plugins are distributed with Mercurial, I can also
activate them when I don't control the Mercurial installation - and should
something be missing which I need, I can just download and activate a plugin
without having to compile anything, since they are simply Python modules.
Just set
[extensions]
foo = /blah/foo.py
in ~/.hgrc and the foo plugin is active.
Gits missing plugin system might just be a reason, why its usability still
suffers from many problems: They have to do everything for everyone all the
time, so the chances are high, that they won't do it really good for anyone
(but the main git coders).
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Random patches from my tree
From: Linus Torvalds @ 2008-10-27 20:37 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810271256470.3386@nehalem.linux-foundation.org>
On Mon, 27 Oct 2008, Linus Torvalds wrote:
>
> So the second one allows things like
>
> git log --pretty=oneline --source --all
A better example may have --abbrev-commit, at which point my current git
tree looks like this for me:
52be8b3... refs/heads/master Add a 'source' decorator for commits
affba33... refs/heads/master Add file delete/create info when we overflow rename
6806f78... refs/remotes/origin/pu Merge branch 'ar/mksnpath' into pu
058412d... refs/remotes/origin/pu Fix potentially dangerous uses of mkpath and g
356af64... refs/remotes/origin/pu Merge branch 'ar/maint-mksnpath' into HEAD
9fa03c1... refs/remotes/origin/pu Fix potentially dangerous uses of mkpath and g
94cc355... refs/remotes/origin/pu Fix mkpath abuse in dwim_ref and dwim_log of s
108bebe... refs/remotes/origin/pu Add mksnpath which allows you to specify the o
6af1fc2... refs/remotes/origin/man Autogenerated manpages for v1.6.0.3-523-g304d
61b1229... refs/remotes/origin/html Autogenerated HTML docs for v1.6.0.3-523-g30
f3ce133... refs/remotes/origin/pu Merge branch 'jc/send-pack-tell-me-more' into
2b37e3a... refs/remotes/origin/pu Merge branch 'jk/renamelimit' into pu
..
ie you can see the the branch that the commits are on.
An example of the ambiguous nature would be
304d058... refs/remotes/origin/HEAD Merge branch 'maint'
ie because the HEAD and 'master' branches of refs/remotes/origin are the
same, it's ambiguous which one to take, and git will have picked one at
random. And obviously when you hit a point where two branches meet again,
it really will depend on which branch we happened to be parsing at the
time (which generally is "which branch had a commit date that was further
back in history").
Another known deficiency: "gitk --source" doesn't work (neither does "gitk
--decorate" for that matter). gitk gets very upset indeed if you try, and
sucks up CPU cycles in some infinite loop.
Linus
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 20:37 UTC (permalink / raw)
To: Brandon Casey; +Cc: Arne Babenhauserheide, mercurial, SLONIK.AZ, git
In-Reply-To: <b6jwksWkldU6N726dbI3k3yYE6WL1aXJERb9Oh1lNd8g5zdTavgRew@cipher.nrlssc.navy.mil>
On Mon, 27 Oct 2008, Brandon Casey wrote:
> Jakub Narebski wrote:
> > On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> > >
> > > Also, looking at git, git users still have to garbage collect regularly, which
> > > shows to me that the design wasn't really cleaner.
> >
> > Well, they have to a lot less than they used to, and there is
> > "git gc --auto" that can be put in crontab safely.
>
> I think you missed the most convincing argument _for_ explicit garbage collection.
>
> By allowing explicit repository packing, git allows you to delay a cpu intensive
> operation til later, when time doesn't matter, like at the end of the day right
> before I go home. It also allows more cpu intensive delta/compression algorithms
> to be used.
>
> By contrast, mercurial performs deltafication and compression on each commit.
> So, acceptable commit speed must be weighed against the complexity of the
> deltafication/compression algorithm and file format.
On the one hand one can use different compression for loose (immediate)
and packed (in a free time) objects.
On the other access from "smart" client (git://, ssh://, future "smart"
HTTP server) results in creating a pack, so we cannot allow for too
tight pack compression, or to be more exact too much CPU load taken.
The ability to vary 'quality' of pack compression is very useful to
distinguish between very loosely packed fast-import pack, and tightly
repacked in free time.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Brandon Casey @ 2008-10-27 20:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Arne Babenhauserheide, mercurial, SLONIK.AZ, git
In-Reply-To: <200810270252.23392.jnareb@gmail.com>
Jakub Narebski wrote:
> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
>> Also, looking at git, git users still have to garbage collect regularly, which
>> shows to me that the design wasn't really cleaner.
>
> Well, they have to a lot less than they used to, and there is
> "git gc --auto" that can be put in crontab safely.
I think you missed the most convincing argument _for_ explicit garbage collection.
By allowing explicit repository packing, git allows you to delay a cpu intensive
operation til later, when time doesn't matter, like at the end of the day right
before I go home. It also allows more cpu intensive delta/compression algorithms
to be used.
By contrast, mercurial performs deltafication and compression on each commit.
So, acceptable commit speed must be weighed against the complexity of the
deltafication/compression algorithm and file format.
-brandon
^ permalink raw reply
* [PATCH 2/2] Add a 'source' decorator for commits
From: Linus Torvalds @ 2008-10-27 20:07 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810271305500.3386@nehalem.linux-foundation.org>
We already support decorating commits by tags or branches that point to
them, but especially when we are looking at multiple branches together,
we sometimes want to see _how_ we reached a particular commit.
We can abuse the '->util' field in the commit to keep track of that as
we walk the commit lists, and get a reasonably useful view into which
branch or tag first reaches that commit.
Of course, if the commit is reachable through multiple sources (which is
common), our particular choice of "first" reachable is entirely random
and depends on the particular path we happened to follow.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
builtin-log.c | 2 ++
builtin-rev-list.c | 2 +-
log-tree.c | 8 +++++---
log-tree.h | 2 +-
revision.c | 4 ++++
revision.h | 1 +
6 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index a0944f7..176cbce 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -56,6 +56,8 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
if (!strcmp(arg, "--decorate")) {
load_ref_decorations();
decorate = 1;
+ } else if (!strcmp(arg, "--source")) {
+ rev->show_source = 1;
} else
die("unrecognized argument: %s", arg);
}
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 06cdeb7..857742a 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -100,7 +100,7 @@ static void show_commit(struct commit *commit)
children = children->next;
}
}
- show_decorations(commit);
+ show_decorations(&revs, commit);
if (revs.commit_format == CMIT_FMT_ONELINE)
putchar(' ');
else
diff --git a/log-tree.c b/log-tree.c
index cec3c06..cf7947b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -52,11 +52,13 @@ static void show_parents(struct commit *commit, int abbrev)
}
}
-void show_decorations(struct commit *commit)
+void show_decorations(struct rev_info *opt, struct commit *commit)
{
const char *prefix;
struct name_decoration *decoration;
+ if (opt->show_source && commit->util)
+ printf(" %s", (char *) commit->util);
decoration = lookup_decoration(&name_decoration, &commit->object);
if (!decoration)
return;
@@ -279,7 +281,7 @@ void show_log(struct rev_info *opt)
fputs(diff_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
if (opt->print_parents)
show_parents(commit, abbrev_commit);
- show_decorations(commit);
+ show_decorations(opt, commit);
if (opt->graph && !graph_is_commit_finished(opt->graph)) {
putchar('\n');
graph_show_remainder(opt->graph);
@@ -352,7 +354,7 @@ void show_log(struct rev_info *opt)
printf(" (from %s)",
diff_unique_abbrev(parent->object.sha1,
abbrev_commit));
- show_decorations(commit);
+ show_decorations(opt, commit);
printf("%s", diff_get_color_opt(&opt->diffopt, DIFF_RESET));
if (opt->commit_format == CMIT_FMT_ONELINE) {
putchar(' ');
diff --git a/log-tree.h b/log-tree.h
index 3c8127b..f2a9008 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -12,7 +12,7 @@ int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
int log_tree_opt_parse(struct rev_info *, const char **, int);
void show_log(struct rev_info *opt);
-void show_decorations(struct commit *commit);
+void show_decorations(struct rev_info *opt, struct commit *commit);
void log_write_email_headers(struct rev_info *opt, const char *name,
const char **subject_p,
const char **extra_headers_p,
diff --git a/revision.c b/revision.c
index 2f646de..d45f05a 100644
--- a/revision.c
+++ b/revision.c
@@ -199,6 +199,8 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object
mark_parents_uninteresting(commit);
revs->limited = 1;
}
+ if (revs->show_source && !commit->util)
+ commit->util = (void *) name;
return commit;
}
@@ -484,6 +486,8 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
if (parse_commit(p) < 0)
return -1;
+ if (revs->show_source && !p->util)
+ p->util = commit->util;
p->object.flags |= left_flag;
if (!(p->object.flags & SEEN)) {
p->object.flags |= SEEN;
diff --git a/revision.h b/revision.h
index 2fdb2dd..51a4863 100644
--- a/revision.h
+++ b/revision.h
@@ -53,6 +53,7 @@ struct rev_info {
left_right:1,
rewrite_parents:1,
print_parents:1,
+ show_source:1,
reverse:1,
reverse_output_stage:1,
cherry_pick:1,
--
1.6.0.3.517.g759a.dirty
^ 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