* Re: [patch] fix imap-send for OSX
From: Junio C Hamano @ 2006-03-15 23:50 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86slpj5ljp.fsf@blue.stonehenge.com>
Thanks.
How much would we care about non GNU libc I wonder. We could
just lose that private definition, and say
#define _GNU_SOURCE
#include <stdio.h>
instead, in git-compat-util.h.
But let's leave that to later rounds.
^ permalink raw reply
* Re: [PATCH] Let merge set the default strategy.
From: Junio C Hamano @ 2006-03-15 23:40 UTC (permalink / raw)
To: Mark Hollomon; +Cc: git
In-Reply-To: <1142463103-6986-markhollomon@comcast.net>
Mark Hollomon <markhollomon@comcast.net> writes:
> If the user does not set a merge strategy for git-pull,
> let git-merge calculate a default strategy.
Makes lot of sense, thanks.
> This may be preferable to the earlier patch involving
> NO_PYTHON.
Which earlier patch???
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-15 23:35 UTC (permalink / raw)
To: Qingning Huo; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0603151450070.3618@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 15 Mar 2006, Junio C Hamano wrote:
>>
>> If we do the dash-form for consistency's sake, we should do
>> PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
>> so.
>
> Yes. That would make sense too. Then git-setup-sh would look more like
> what the builtin git.c does.
I think some historical background is in order.
We started without bindir vs execdir distinction but we wanted a
way to someday migrate out of putting everything in bindir. As
one part of the solution, "git" wrapper was invented, and as the
result of that effort, some parts of the scripts, and lot of
documentation pages and sample scripts, lost dashes.
Historically, git tools have always wanted everything git-* to
be found on user's PATH, and we were alarmed to see 100+ git-*
commands in /usr/bin. That's why "git" wrapper and
GIT_EXEC_PATH environment were invented. People can have
/usr/bin/git and no other git-* on their PATH, because that
"git" knows where to find the rest of git-* commands. For that
to work, the scripts should know where to find the rest -- and
cleanest way is to run others via "git foo" form.
Consistency via s/git-foo/git foo/g _is_ the goal, but that kind
of change interferes with the other patches that do the real
work, and it is kind of boring, so nobody has done wholesale
clean-up of all the scripts.
Invoking with the full path is not an option -- it makes
building and testing-before-installing process too cumbersome.
You are welcome to try and send in a patch to do that if (and
only if) you volunteer to go the whole nine yards, but I have to
warn you that that approach is something we have already
considered and discarded, one reason why is because it makes the
testsuite unworkable (testing needs to be done before
installing).
If you want to use the other "git" (GNU interactive tools, which
I once heard is changing its name to gitfm or something like
that -- how nice of them -- but has it ever happened?), and if
you want to have /usr/bin (which has that "git") and then
/other/bin (which has on-topic "git") on your PATH, in that
order, that would be a problem. Saying just "git" would invoke
other "git" that does not know what to do.
If you can solve that without hardcoding the full path in our
scripts, that would be ideal. But otherwise, especially with
changing things back to "git-foo" form without making sure going
backward in that way would not hinder the migration out of
/usr/bin, then that creates more problems than it solves.
So that is why I said I would prefer dashless form.
I _think_ the simplest fix is to change the order of directories
you list on your PATH so that "git" is found before GNU
interactive tool, which is my impression that most people seem
to do (many in fact do not have GNU interactive tool on their
PATH anywhere).
^ permalink raw reply
* [patch] fix imap-send for OSX
From: Randal L. Schwartz @ 2006-03-15 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6avgxva.fsf@assigned-by-dhcp.cox.net>
This patch works... I've been using it to stay current.
---
imap-send.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
ba458b49b860488c25cf57dabbb5db97f12e41f2
diff --git a/imap-send.c b/imap-send.c
index 1b38b3a..e33c78b 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -372,7 +372,7 @@ free_generic_messages( message_t *msgs )
}
static int
-vasprintf( char **strp, const char *fmt, va_list ap )
+git_vasprintf( char **strp, const char *fmt, va_list ap )
{
int len;
char tmp[1024];
@@ -402,7 +402,7 @@ nfsnprintf( char *buf, int blen, const c
static int
nfvasprintf( char **str, const char *fmt, va_list va )
{
- int ret = vasprintf( str, fmt, va );
+ int ret = git_vasprintf( str, fmt, va );
if (ret < 0)
die( "Fatal: Out of memory\n");
return ret;
--
1.2.4.g5593
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply related
* Re: [PATCH] Invoke git-repo-config directly.
From: Linus Torvalds @ 2006-03-15 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Qingning Huo, git
In-Reply-To: <7vek13ieap.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Mar 2006, Junio C Hamano wrote:
>
> If we do the dash-form for consistency's sake, we should do
> PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
> so.
Yes. That would make sense too. Then git-setup-sh would look more like
what the builtin git.c does.
Linus
^ permalink raw reply
* [PATCH] Let merge set the default strategy.
From: Mark Hollomon @ 2006-03-15 22:51 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, markhollomon
If the user does not set a merge strategy for git-pull,
let git-merge calculate a default strategy.
This may be preferable to the earlier patch involving
NO_PYTHON.
Signed-off-by: Mark Hollomon <markhollomon@comcast.net>
---
git-pull.sh | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
54e2c920b8ad979bc75d25ae73300be6077f46a0
diff --git a/git-pull.sh b/git-pull.sh
index 6caf1aa..7764b70 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -71,19 +71,15 @@ case "$merge_head" in
;;
?*' '?*)
var=`git repo-config --get pull.octopus`
- if test '' = "$var"
+ if test '' != "$var"
then
- strategy_default_args='-s octopus'
- else
strategy_default_args="-s $var"
fi
;;
*)
var=`git repo-config --get pull.twohead`
- if test '' = "$var"
- then
- strategy_default_args='-s recursive'
- else
+ if test '' != "$var"
+ then
strategy_default_args="-s $var"
fi
;;
--
1.2.4.gea75
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-03-15 22:13 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
- git-svn updates (Eric Wong)
- git-blame knows about renames (Fredrik Kuivinen)
- imap-send (Mike McCormack with fixes from Johannes Schindelin
and Marco Roeland)
- cvsimport only updates tracking branch (Matthias Urlichs)
- repo-config fix (Jonas Fonseca)
- fmt-merge-msg cleanup (Linus Torvalds)
- format-patch attachments enhancements (Mike McCormack)
- delitifier cleanup and performance fix (Nicolas Pitre)
- remove end-of-line period from git-pull message (Olaf Hering)
- http-push and fetch updates (Nick Hengeveld)
- rev-list and revision walker performance fix (Matthias Urlichs)
- annotate RPM packaging workaround (sean)
- assorted doc fixes (Francis Daly, Fredrik Kuivinen)
- assorted test fixes (Mark Wooding, me)
- improve git wrapper --help output (Fredrik Kuivinen)
- checkout-index --temp (Shawn Pearce)
- no more --standalone to fsck-objects
- rev-list path limiter fix at boundary
- git-diff: -p disables rename detection
As you can see from the above, the core part does not have
drastic changes these days anymore. Just some boring fixes with
a handful new and interesting developments.
In the "next" branch is the "insanely fast rename detection".
I've done some minor fixups to its hash function to be usable on
both 32-bit and 64-bit machines but otherwise it is what was
posted by Linus to the list. It completes the rename detection
between v2.6.12 and v2.6.14 kernel source under 5 seconds on my
Duron 750 with slow disks, where the current "master" branch
version takes about 60 seconds.
Also I've been keeping ls-{tree,files} --abbrev patches and
refs/remotes patch from Eric Wong in 'next' and 'pu'. I haven't
seen anybody jumps up and down to have them merged to "master",
nor have been asked to push them out sooner so that a widely
used Porcelain or two can take advantage of them, and that's the
only reason why they are not in "master". In other words, while
I do not have much against them, it would be nicer to have a
convincing argument why they are must-have's or even
better-have's before they graduate.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-15 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbrie79.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 15, 2006 at 01:35:22PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Linus Torvalds <torvalds@osdl.org> writes:
> >
> >> I agree that it is inconsistent as-is. So a patch to make it use the
> >> "git-repo-config" form (the argument being that internally, we use the
> >> full names) might be good if just for consistency.
> >
> > If we do the dash-form for consistency's sake,...
>
> Probably I should add that personally my preference is to standardize on
> the dashless form.
>
That would remove the possibility to run "git-push" in my scenario. And
what is the benefit? Wasting CPU cycles to an extra execve?
Duplicating git --exec-path to PATH?
Personally I recommend to always run git helper programs with absolute
path, this would remove all confusions, not play with users' PATH
environment, and save CPU cycles.
Qingning
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-15 21:35 UTC (permalink / raw)
To: git
In-Reply-To: <7vek13ieap.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
(replying to myself ...)
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> I agree that it is inconsistent as-is. So a patch to make it use the
>> "git-repo-config" form (the argument being that internally, we use the
>> full names) might be good if just for consistency.
>
> If we do the dash-form for consistency's sake,...
Probably I should add that personally my preference is to standardize on
the dashless form.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-15 21:33 UTC (permalink / raw)
To: Qingning Huo; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0603141506130.3618@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I agree that it is inconsistent as-is. So a patch to make it use the
> "git-repo-config" form (the argument being that internally, we use the
> full names) might be good if just for consistency.
If we do the dash-form for consistency's sake, we should do
PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
so. For scripts that do not use git-setup-sh they must have
their own.
This would make difference if/when we switch to
/usr/lib/git/exec, but until then it is not.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-15 20:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603141506130.3618@g5.osdl.org>
On Tue, Mar 14, 2006 at 03:07:39PM -0800, Linus Torvalds wrote:
> On Tue, 14 Mar 2006, Qingning Huo wrote:
> > We have "git-read-tree" and "git repo-config" at the same time. Are
> > there any rules saying which form should be preferred? How about pick
> > one form and stick to it?
>
> I agree that it is inconsistent as-is. So a patch to make it use the
> "git-repo-config" form (the argument being that internally, we use the
> full names) might be good if just for consistency.
>
Can these two patches be accepted then? What do others think?
Qingning
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Andreas Ericsson @ 2006-03-15 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Jakma, git, Linus Torvalds
In-Reply-To: <7vlkvbik8f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Can't this be done by updating .git/index first and then use the
>>temporary index to commit? Then .git/index would match the current
>>tree and everybody would be happy with very little tweaking. Doing the
>>temporary index commit first could cause data-loss as described above
>>if the updating of .git/index somehow fails and the user is unaware of
>>it (or what to do to fix it).
>
>
> You have to think about how to rewind it when the user decides
> later not to commit by for example giving an empty commit
> message or killing the editor. The order of things need to be
> to populate the index to be committed so that we can give
> preview in the commit log template upon 'commit -v', spawn the
> editor and get the final version of log, and then make a
> commit. So it may or may not be doable -- I haven't thought
> about it through, and currently have not much incentive nor
> inclination to think about it myself right now.
>
cp .git/index .git/pre-commit-index
and roll it back if the user aborts. Should work, but like you I don't
need that functionality, so...
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Junio C Hamano @ 2006-03-15 19:25 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Paul Jakma, git, Linus Torvalds
In-Reply-To: <44181DFE.7080204@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Can't this be done by updating .git/index first and then use the
> temporary index to commit? Then .git/index would match the current
> tree and everybody would be happy with very little tweaking. Doing the
> temporary index commit first could cause data-loss as described above
> if the updating of .git/index somehow fails and the user is unaware of
> it (or what to do to fix it).
You have to think about how to rewind it when the user decides
later not to commit by for example giving an empty commit
message or killing the editor. The order of things need to be
to populate the index to be committed so that we can give
preview in the commit log template upon 'commit -v', spawn the
editor and get the final version of log, and then make a
commit. So it may or may not be doable -- I haven't thought
about it through, and currently have not much incentive nor
inclination to think about it myself right now.
^ permalink raw reply
* [PATCH] Fix broken slot reuse when fetching alternates
From: Nick Hengeveld @ 2006-03-15 16:59 UTC (permalink / raw)
To: git
When fetching alternates, http-fetch may reuse the slot to fetch non-http
alternates if http-alternates does not exist. When doing so, it now needs
to update the slot's finished status so run_active_slot waits for the
non-http alternates request to finish.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
e0e27549c5cbc85639f7d329a8a900ca7243130c
diff --git a/http-fetch.c b/http-fetch.c
index 8fd9de0..7de818b 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -468,9 +468,13 @@ static void process_alternates_response(
alt_req->url);
active_requests++;
slot->in_use = 1;
+ if (slot->finished != NULL)
+ (*slot->finished) = 0;
if (!start_active_slot(slot)) {
got_alternates = -1;
slot->in_use = 0;
+ if (slot->finished != NULL)
+ (*slot->finished) = 1;
}
return;
}
--
1.2.4.gea75-dirty
^ permalink raw reply related
* Re: git merge in FreeBSD
From: Eric Anholt @ 2006-03-15 16:42 UTC (permalink / raw)
To: Rajkumar S; +Cc: git
In-Reply-To: <44182A3C.80701@asianetindia.com>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Wed, 2006-03-15 at 20:22 +0530, Rajkumar S wrote:
> Hi,
>
> I get a "git-merge-recursive: not found" error when I try to do a merge in FreeBSD. Same
> command in Linux does not give an error.
>
> # git merge "Merging from updates" RELENG_1 RELENG_1_origin
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
> Nope.
> /usr/local/bin/git-merge: git-merge-recursive: not found
> No merge strategy handled the merge.
>
> I am using git version 1.2.4.gea75 in FreeBSD 6
This is probably the wrong python path in git-merge-recursive. I've got
a fix on my laptop for this and gitk, but I haven't tried submitting it
again (I guess email was hosed, or it got lost, when I sent the first
version of it directly to Junio).
But might I also recommend ports/devel/git? I'm keeping it pretty up to
date, and using it on a daily basis.
--
Eric Anholt anholt@FreeBSD.org
eric@anholt.net eric.anholt@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* git merge in FreeBSD
From: Rajkumar S @ 2006-03-15 14:52 UTC (permalink / raw)
To: git
Hi,
I get a "git-merge-recursive: not found" error when I try to do a merge in FreeBSD. Same
command in Linux does not give an error.
# git merge "Merging from updates" RELENG_1 RELENG_1_origin
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
/usr/local/bin/git-merge: git-merge-recursive: not found
No merge strategy handled the merge.
I am using git version 1.2.4.gea75 in FreeBSD 6
raj
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Andreas Ericsson @ 2006-03-15 14:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Jakma, git, Linus Torvalds
In-Reply-To: <7vy7zcie5c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The background behind this is around beginning of February 2006,
> the thread "Two ideas" by Carl Worth. And the current behaviour
> is defined by this commit. I'll talk about a possible
> improvement but first, here is what it does:
>
> commit 130fcca63fe8e7e087e7419907e018cbbaf434a3
> Author: Junio C Hamano <junkio@cox.net>
> Date: Sun Feb 5 00:07:44 2006 -0800
>
>
> 2. refuses to run if named paths... are different in HEAD and
> the index (ditto about reminding). Added paths are OK.
>
>
> The check that prevents you from doing
>
> $ edit A B
> $ git update-index A B
> $ git commit -o B
>
> is the rule #2, which I think could use further improvement. It
> is to address the "committing skewed files" issue Carl brought
> up in that thread.
>
> It might be better to further check if the working tree file is
> the same as the index, and to allow a commit in such a case.
>
> The intent of rule #2 is to prevent this from happening:
>
> $ edit A B
> $ git update-index A B
> $ edit B again
> $ git commit -o B
>
> When this happens, the real index will have _old_ contents of B
> that never was committed, and does not match what is in the
> index. But after the commit, we will match the real index to
> what was committed, so we will _lose_ the index entry for B
> before the second edit you explicitly told git to remember by
> saying 'update-index'.
>
Can't this be done by updating .git/index first and then use the
temporary index to commit? Then .git/index would match the current tree
and everybody would be happy with very little tweaking. Doing the
temporary index commit first could cause data-loss as described above if
the updating of .git/index somehow fails and the user is unaware of it
(or what to do to fix it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Paul Jakma @ 2006-03-15 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vy7zcie5c.fsf@assigned-by-dhcp.cox.net>
On Tue, 14 Mar 2006, Junio C Hamano wrote:
<snip - interesting, thanks>
> It might be better to further check if the working tree file is the
> same as the index, and to allow a commit in such a case.
That would be a nice improvement.
> The intent of rule #2 is to prevent this from happening:
>
> $ edit A B
> $ git update-index A B
> $ edit B again
> $ git commit -o B
> When this happens, the real index will have _old_ contents of B
> that never was committed, and does not match what is in the index.
> But after the commit, we will match the real index to what was
> committed, so we will _lose_ the index entry for B before the
> second edit you explicitly told git to remember by saying
> 'update-index'.
That would indeed be annoying, and I'd obviously prefer to have to
run 'git reset' than have the above happen!
However, I'd have expected that any porcelain command would
synchronise index with HEAD after a commit. See below for my (still
newbie-ish ;) ) user-level mental model of git.
> On the other hand, in your original sequence:
>
> $ edit A B
> $ git update-index A B
> $ git commit -o B
>
> B being committed would be different between HEAD and index, but
> that is what we are going to commit anyway, so after this commit, B
> will be in sync with the updated HEAD.
Right. So if the file in the index and working tree are the same
(hey, i just ran update-index after all), then that check could be
loosened. The only thing the commit can do is bring the /3rd/ piece
of the puzzle (HEAD) in sync :).
> To put it in another way, "commit -o" is a short-hand for people
> who do not want to run update-index themselves (IOW, people who
> just want to use git without worrying about the index file). If
> you use update-index to mark "this is what I want to commit"
> yourself, you should do so consistently. If you are not ready to
> commit A but you want to commit B, do not mark both of them and
> expect "commit -o" to do magic fixups.
I guess my problem here is that I consider the index to be a 'weak'
cache.
I like to use it for intermediate way-points or "weak commits",
however if I commit to HEAD I /really/ want what (I consider to be)
the two /strong/ sources of file information (HEAD and working file)
to be synchronised, and the 'weak' cache updated then to match.
I wasn't expecting the 'weak' cache of the index to prevent me
synchronising my 'strong' sources (HEAD and working file). I was
expecting the 'weak' cache to be updated to the 'strong' ones.
If I want to synchronise this 'weak' cache, I'll do so explicitely
(though, there isn't a user-obvious distinction in commands for this,
there's no obvious "git-commit-index"). Maybe part of the problem
here is that git-commit tries to hide the index/working-tree/HEAD
distinction? I don't know.
Anyway, if git-commit can lift "Rule 2" where file in working tree
and index match, that'd be great - but I can easily live with
git-reset till then. ;)
Thanks for the informative email!
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
A violent man will die a violent death.
-- Lao Tsu
^ permalink raw reply
* Re: any problems with new branch of gitk?
From: Alex Riesen @ 2006-03-15 13:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17431.63509.670409.212654@cargo.ozlabs.ibm.com>
On 3/15/06, Paul Mackerras <paulus@samba.org> wrote:
>
> > I don't if that was intended (see the screenshot attached), but some
> > lines miss arrows. Click on where the arrow would be works (jump to
> > counterpart arrow). Never have this with the old gitk.
> >
> > Tcl/Tk 8.4.9 (Gentoo).
>
> Yes, it seems that tk 8.4 can't draw arrows on the ends of diagonal
> line segments. The old gitk coped with this by simply shortening the
> line until it got to a vertical line segment. I can probably do
> better than that with the new layout algorithm. I'll look at it.
>
Ok, thanks for confirmation. I wasn't sure if that's me, Gentoo, or tk.
On related note: do you know of any way to start gitk with sensible
layout under cygwin? I ended up with commenting out sourcing of
.gitk. It produces a window compressed in one block, which I can
resize and relayout later. Any other attempt to preset the size or
layout either can't be (literally) seen or can't be changed into something
usable.
^ permalink raw reply
* Re: any problems with new branch of gitk?
From: Paul Mackerras @ 2006-03-15 11:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060306202340.GA5946@steel.home>
Alex Riesen writes:
> I don't if that was intended (see the screenshot attached), but some
> lines miss arrows. Click on where the arrow would be works (jump to
> counterpart arrow). Never have this with the old gitk.
>
> Tcl/Tk 8.4.9 (Gentoo).
Yes, it seems that tk 8.4 can't draw arrows on the ends of diagonal
line segments. The old gitk coped with this by simply shortening the
line until it got to a vertical line segment. I can probably do
better than that with the new layout algorithm. I'll look at it.
Paul.
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Junio C Hamano @ 2006-03-15 3:24 UTC (permalink / raw)
To: Paul Jakma; +Cc: git, Linus Torvalds
In-Reply-To: <7vwtewk2jp.fsf@assigned-by-dhcp.cox.net>
The background behind this is around beginning of February 2006,
the thread "Two ideas" by Carl Worth. And the current behaviour
is defined by this commit. I'll talk about a possible
improvement but first, here is what it does:
commit 130fcca63fe8e7e087e7419907e018cbbaf434a3
Author: Junio C Hamano <junkio@cox.net>
Date: Sun Feb 5 00:07:44 2006 -0800
...
- "git commit paths..." acquires a new semantics. This is an
incompatible change that needs user training, which I am
still a bit reluctant to swallow, but enough people seem to
have complained that it is confusing to them. It
1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds
trained git users that the traditional semantics now needs
-i flag.
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding). Added paths are OK.
3. reads HEAD commit into a temporary index file.
4. updates named paths... from the working tree in this
temporary index.
5. does the same updates of the paths... from the working
tree to the real index.
6. makes a commit using the temporary index that has the
current HEAD as the parent, and updates the HEAD with this
new commit.
...
The check that prevents you from doing
$ edit A B
$ git update-index A B
$ git commit -o B
is the rule #2, which I think could use further improvement. It
is to address the "committing skewed files" issue Carl brought
up in that thread.
It might be better to further check if the working tree file is
the same as the index, and to allow a commit in such a case.
The intent of rule #2 is to prevent this from happening:
$ edit A B
$ git update-index A B
$ edit B again
$ git commit -o B
When this happens, the real index will have _old_ contents of B
that never was committed, and does not match what is in the
index. But after the commit, we will match the real index to
what was committed, so we will _lose_ the index entry for B
before the second edit you explicitly told git to remember by
saying 'update-index'.
On the other hand, in your original sequence:
$ edit A B
$ git update-index A B
$ git commit -o B
B being committed would be different between HEAD and index, but
that is what we are going to commit anyway, so after this
commit, B will be in sync with the updated HEAD.
To put it in another way, "commit -o" is a short-hand for people
who do not want to run update-index themselves (IOW, people who
just want to use git without worrying about the index file). If
you use update-index to mark "this is what I want to commit"
yourself, you should do so consistently. If you are not ready
to commit A but you want to commit B, do not mark both of them
and expect "commit -o" to do magic fixups.
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Junio C Hamano @ 2006-03-14 23:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Paul Jakma
In-Reply-To: <Pine.LNX.4.64.0603140915290.3618@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I also think that test is historical, from before Junio cleaned up how
> "git commit" worked - it _used_ to be that "git commit" would work in the
> current index, but these days it generates a new index to commit when you
> do "-o", so there's really no _technical_ reason to refuse the partial
> commit any more as far as I can see.
>
> So I don't know. I don't think you were being dumb, I think git could have
> been friendlier to you.
I have to go back to the list archive, but if I recall correctly
the refusal was added to be friendlier -- by being safer -- and
was not there in the earlier round of -o/-i proposal.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Linus Torvalds @ 2006-03-14 23:07 UTC (permalink / raw)
To: Qingning Huo; +Cc: Git Mailing List
In-Reply-To: <20060314224027.GB14733@localhost.localdomain>
On Tue, 14 Mar 2006, Qingning Huo wrote:
>
> Thanks for your detailed explanation. Yes, "git push" and "git pull"
> both work fine out of the box. That is the good thing. But,
>
> $ grep git git-pull.sh
>
> . git-sh-setup
> orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
> git-fetch --update-head-ok "$@" || exit 1
> curr_head=$(git-rev-parse --verify HEAD)
> git-read-tree -u -m "$orig_head" "$curr_head" ||
> var=`git repo-config --get pull.octopus`
> var=`git repo-config --get pull.twohead`
> merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
> git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
>
> We have "git-read-tree" and "git repo-config" at the same time. Are
> there any rules saying which form should be preferred? How about pick
> one form and stick to it?
I agree that it is inconsistent as-is. So a patch to make it use the
"git-repo-config" form (the argument being that internally, we use the
full names) might be good if just for consistency.
Linus
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-14 22:40 UTC (permalink / raw)
To: Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0603141351470.3618@g5.osdl.org>
On Tue, Mar 14, 2006 at 01:58:09PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 14 Mar 2006, Qingning Huo wrote:
> >
> > The system have GNU git installed at /usr/bin/git. I installed git-core
> > to ~/opt/bin. ~/opt/bin is in my PATH, but is after /usr/bin. I have
> > set alias git="$HOME/opt/bin/git".
>
> This should not be a problem with the modern "git.c" wrapper. It
> _should_, if you call it with the full path, automatically prepend that
> path to the PATH when executing sub-commands.
>
> So if you run git as "$HOME/opt/bin/git", the PATH _should_ be
> - first the "PREFIX/bin" path as defined by the build
> - second the "$HOME/opt/bin/" path as defined by the fact that you ran
> git from that path
> - finally the normal $PATH.
>
> To check this out, do this:
>
> ln -s /usr/bin/printenv ~/opt/bin/git-printenv
> git printenv
>
> and you should see the proper PATH that git ends up using internally that
> way.
>
> So your problem seems to be that you do "git-pull", when you really should
> do "git pull" (where that wrapper will set up PATH for you). Since you
> don't use the wrapper, the scripts end up doing the wrong thing.
>
Thanks for your detailed explanation. Yes, "git push" and "git pull"
both work fine out of the box. That is the good thing. But,
$ grep git git-pull.sh
. git-sh-setup
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
git-fetch --update-head-ok "$@" || exit 1
curr_head=$(git-rev-parse --verify HEAD)
git-read-tree -u -m "$orig_head" "$curr_head" ||
var=`git repo-config --get pull.octopus`
var=`git repo-config --get pull.twohead`
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
We have "git-read-tree" and "git repo-config" at the same time. Are
there any rules saying which form should be preferred? How about pick
one form and stick to it?
If we uniformly call git helper programs/scripts with "git helper"
style, would git(1) append two paths to PATH everytime it is being
invoked? For example, "git pull" -> "git repo-config" would prepend
~/opt/bin four times to PATH. This wouldn't be very effecient.
Regards,
Qingning
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Linus Torvalds @ 2006-03-14 21:58 UTC (permalink / raw)
To: Qingning Huo; +Cc: git, junkio
In-Reply-To: <20060314211022.GA12498@localhost.localdomain>
On Tue, 14 Mar 2006, Qingning Huo wrote:
>
> The system have GNU git installed at /usr/bin/git. I installed git-core
> to ~/opt/bin. ~/opt/bin is in my PATH, but is after /usr/bin. I have
> set alias git="$HOME/opt/bin/git".
This should not be a problem with the modern "git.c" wrapper. It
_should_, if you call it with the full path, automatically prepend that
path to the PATH when executing sub-commands.
So if you run git as "$HOME/opt/bin/git", the PATH _should_ be
- first the "PREFIX/bin" path as defined by the build
- second the "$HOME/opt/bin/" path as defined by the fact that you ran
git from that path
- finally the normal $PATH.
To check this out, do this:
ln -s /usr/bin/printenv ~/opt/bin/git-printenv
git printenv
and you should see the proper PATH that git ends up using internally that
way.
So your problem seems to be that you do "git-pull", when you really should
do "git pull" (where that wrapper will set up PATH for you). Since you
don't use the wrapper, the scripts end up doing the wrong thing.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox