* 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
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-14 21:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0603142219040.23646@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Mar 14, 2006 at 10:20:53PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 14 Mar 2006, Qingning Huo wrote:
>
> > - var=`git repo-config --get pull.octopus`
> > + var=`git-repo-config --get pull.octopus`
>
> This is unlikely to be applied; there are plans to have a "libexec" path
> in which all git executables are stored, and just the "git" wrapper in the
> path. Your patch would break git in those setups.
>
I do not mind whether this patch is applied. What I want is git calls
its helper programs, instead of any random git program in my PATH. If
git-programs are installed to libexec path, how about calling them
with absolute path?
Regards,
Qingning
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Johannes Schindelin @ 2006-03-14 21:20 UTC (permalink / raw)
To: Qingning Huo; +Cc: git, junkio
In-Reply-To: <20060314211022.GA12498@localhost.localdomain>
Hi,
On Tue, 14 Mar 2006, Qingning Huo wrote:
> - var=`git repo-config --get pull.octopus`
> + var=`git-repo-config --get pull.octopus`
This is unlikely to be applied; there are plans to have a "libexec" path
in which all git executables are stored, and just the "git" wrapper in the
path. Your patch would break git in those setups.
Ciao,
Dscho
P.S.: BTW there are quite a few discussions of this in the mailing list
archives...
^ permalink raw reply
* [PATCH] Invoke git-stripspace directly.
From: Qingning Huo @ 2006-03-14 21:11 UTC (permalink / raw)
To: git; +Cc: junkio
Run "git-stripspace" instead of "git stripspace" to avoid calling
external git command.
Signed-off-by: Qingning Huo <qhuo@mayhq.co.uk>
---
git-format-patch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
aad41923a43b82713af05eaa26db688272091520
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 2ebf7e8..486fb31 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -213,7 +213,7 @@ sub show_date {
}
print "From nobody Mon Sep 17 00:00:00 2001\n";
-open FH, "git stripspace <$commsg |" or die "open $commsg pipe";
+open FH, "git-stripspace <$commsg |" or die "open $commsg pipe";
while (<FH>) {
unless ($done_header) {
if (/^$/) {
--
1.2.4.ga019-dirty
^ permalink raw reply related
* [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-14 21:10 UTC (permalink / raw)
To: git; +Cc: junkio
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".
git-push and git-pull behaves strangely, because they call "git
repo-config", which runs /usr/bin/git. Using "git-repo-config" directly
fixed the problem.
Signed-off-by: Qingning Huo <qhuo@mayhq.co.uk>
---
git-pull.sh | 4 ++--
git-sh-setup.sh | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
a0194fff002cb12ac58b202201d387f8ea55b225
diff --git a/git-pull.sh b/git-pull.sh
index 6caf1aa..e32e2b0 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -70,7 +70,7 @@ case "$merge_head" in
exit 0
;;
?*' '?*)
- var=`git repo-config --get pull.octopus`
+ var=`git-repo-config --get pull.octopus`
if test '' = "$var"
then
strategy_default_args='-s octopus'
@@ -79,7 +79,7 @@ case "$merge_head" in
fi
;;
*)
- var=`git repo-config --get pull.twohead`
+ var=`git-repo-config --get pull.twohead`
if test '' = "$var"
then
strategy_default_args='-s recursive'
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 025ef2d..12f5ede 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -41,7 +41,7 @@ then
: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
# Make sure we are in a valid repository of a vintage we understand.
- GIT_DIR="$GIT_DIR" git repo-config --get core.nosuch >/dev/null
+ GIT_DIR="$GIT_DIR" git-repo-config --get core.nosuch >/dev/null
if test $? = 128
then
exit
--
1.2.4.ga019-dirty
^ permalink raw reply related
* git-cvsimport missed a commit
From: Paul Jakma @ 2006-03-14 17:34 UTC (permalink / raw)
To: git list
git-cvsimport missed a commit (one involving 'renamed' files in CVS,
added/deleted).
I'm wondering how best to fix this. My thinking was to just branch my
'cvs_head' from the ancestor prior the missed commit, rename the
heads around, and try again.
Is there a better way? Given I actually have the missing commit in my
'master' branch?
(I actually have a 2-way thing going with CVS. I export selected
commit from master to CVS every now and then, and get my own CVS
commits back again via a later import - seems to work).
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
So much food; so little time!
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Paul Jakma @ 2006-03-14 17:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0603140915290.3618@g5.osdl.org>
On Tue, 14 Mar 2006, Linus Torvalds wrote:
> Well, I actually think git is being somewhat of an ass, for no
> really good reason. It's true that you are doing something pretty
> strange by _both_ using "git-update-index" and "git commit -o" but
> the fact is, at least when adding files, that would be expected (ie
> you have to mark a file in the index to add it).
Well, I tend to work on one thing, then notice something else
unrelated (or in a support file), fix/tweak that, etc.. I use the
index for 'way-point' diffs, rather than commit things I havn't quite
tested yet (or dont know whether they'll be useful yet).
> 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.
Aha. So that check possibly could just be removed?
> So I don't know. I don't think you were being dumb, I think git
> could have been friendlier to you.
:)
git reset works just fine too.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
A day for firm decisions!!!!! Or is it?
^ permalink raw reply
* Re: [PATCH] Use resolve in git-pull if NO_PYTHON
From: Johannes Schindelin @ 2006-03-14 17:26 UTC (permalink / raw)
To: Mark Hollomon; +Cc: git
In-Reply-To: <1142356355-4772-markhollomon@comcast.net>
Hi,
On Tue, 14 Mar 2006, Mark Hollomon wrote:
> git-pull is hardcoded to use the recursive merge strategy
> for the twohead case. But if git has been built with NO_PYTHON,
> that strategy is not available. Teach git-pull to use resolve
> if built with NO_PYTHON.
D'oh. I forgot to send that patch when I was doing the NO_PYTHON stuff.
But I did it differently: There is no good reason that git-pull should
insist on its own default strategy when git-merge already has one.
Ciao,
Dscho
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Linus Torvalds @ 2006-03-14 17:20 UTC (permalink / raw)
To: Paul Jakma; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0603141703080.5276@sheen.jakma.org>
On Tue, 14 Mar 2006, Paul Jakma wrote:
> On Tue, 14 Mar 2006, Linus Torvalds wrote:
>
> > The simplest thing to do is to do
> >
> > git reset
> >
> > to reset your index back to your HEAD (but obviously DON'T use the "-f"
> > flag, which will also force the working tree!).
>
> Ah, of course! (I knew I was being dumb ;) ).
Well, I actually think git is being somewhat of an ass, for no really good
reason. It's true that you are doing something pretty strange by _both_
using "git-update-index" and "git commit -o" but the fact is, at least
when adding files, that would be expected (ie you have to mark a file
in the index to add it).
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.
Linus
^ permalink raw reply
* [PATCH] Use resolve in git-pull if NO_PYTHON
From: Mark Hollomon @ 2006-03-14 17:16 UTC (permalink / raw)
To: git
git-pull is hardcoded to use the recursive merge strategy
for the twohead case. But if git has been built with NO_PYTHON,
that strategy is not available. Teach git-pull to use resolve
if built with NO_PYTHON.
Signed-off-by: Mark Hollomon <markhollomon@comcast.net>
---
git-pull.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
1eb3abec6f4811e3eeafa50445ed0f2ce5d85b08
diff --git a/git-pull.sh b/git-pull.sh
index 6caf1aa..ae9c346 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -8,6 +8,11 @@ USAGE='[-n | --no-summary] [--no-commit]
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
. git-sh-setup
+default_twohead_strategy='recursive'
+if test "@@NO_PYTHON@@"; then
+ default_twohead_strategy='resolve'
+fi
+
strategy_args= no_summary= no_commit=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
@@ -82,7 +87,7 @@ case "$merge_head" in
var=`git repo-config --get pull.twohead`
if test '' = "$var"
then
- strategy_default_args='-s recursive'
+ strategy_default_args="-s $default_twohead_strategy"
else
strategy_default_args="-s $var"
fi
--
1.2.4.g967a
^ permalink raw reply related
* Re: seperate commits for objects already updated in index?
From: Paul Jakma @ 2006-03-14 17:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0603140856120.3618@g5.osdl.org>
On Tue, 14 Mar 2006, Linus Torvalds wrote:
> The simplest thing to do is to do
>
> git reset
>
> to reset your index back to your HEAD (but obviously DON'T use the "-f"
> flag, which will also force the working tree!).
Ah, of course! (I knew I was being dumb ;) ).
> Then you can just do
>
> git commit -o bar
>
> and everything should be fine, because then git doesn't think you're doing
> something insane.
Yep, thank you!
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
The less a statesman amounts to, the more he loves the flag.
-- Kin Hubbard
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Linus Torvalds @ 2006-03-14 17:00 UTC (permalink / raw)
To: Paul Jakma; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0603141634010.5276@sheen.jakma.org>
On Tue, 14 Mar 2006, Paul Jakma wrote:
> Hi,
>
> Dumb question, imagine you made changes to a few files, and ran update-index
> at various stages in between:
>
> $ git status
> #
> # Updated but not checked in:
> # (will commit)
> #
> # modified: foo/ChangeLog
> # modified: foo/whatever
> # modified: bar/ChangeLog
> # modified: bar/other
>
> The changes in bar/ are unrelated to the changes in foo/ - how do you commit
> each seperately? Git doesn't seem to want to let me:
>
> $ git commit -o bar
> Different in index and the last commit:
> M bar/ChangeLog
> M bar/other
> You might have meant to say 'git commit -i paths...', perhaps?
>
> git commit on its own wants to commit all the above files.
>
> what's the silly thing I've missed?
You've already marked them all modified in the index (using
git-update-index), so git commit thinks you are confused by naming them
again and saying "only".
The simplest thing to do is to do
git reset
to reset your index back to your HEAD (but obviously DON'T use the "-f"
flag, which will also force the working tree!). That will make your index
clean, and undo the fact that you've already marked things to be committed
with "git-update-index".
Then you can just do
git commit -o bar
and everything should be fine, because then git doesn't think you're doing
something insane.
Linus
^ permalink raw reply
* seperate commits for objects already updated in index?
From: Paul Jakma @ 2006-03-14 16:37 UTC (permalink / raw)
To: git list
Hi,
Dumb question, imagine you made changes to a few files, and ran
update-index at various stages in between:
$ git status
#
# Updated but not checked in:
# (will commit)
#
# modified: foo/ChangeLog
# modified: foo/whatever
# modified: bar/ChangeLog
# modified: bar/other
The changes in bar/ are unrelated to the changes in foo/ - how do you
commit each seperately? Git doesn't seem to want to let me:
$ git commit -o bar
Different in index and the last commit:
M bar/ChangeLog
M bar/other
You might have meant to say 'git commit -i paths...', perhaps?
git commit on its own wants to commit all the above files.
what's the silly thing I've missed?
Thanks.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Never tell a lie unless it is absolutely convenient.
^ 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