* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-11 2:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vd5iz4mt7.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-01-10 at 16:42 -0800, Junio C Hamano wrote:
> Michal Ostrowski <mostrows@watson.ibm.com> writes:
>
> > How about searching for executables in the following places, and in this
> > order:
> >
> > 1. --exec-path setting, if any
> > 2. GIT_EXEC_PATH env var, if set
> > 3. PATH (never modified)
> > 4. Value of ${bindir} at build time
>
> and then make the rule for git things:
>
> 1. --exec-path
> 2. GIT_EXEC_PATH environment
> 3. $(gitexecdir)
>
> in this order. Non git things should just use $PATH without
> looking at anything else --- as long as a hook script calls a git
> wrapper (i.e. "git foo" not "git-foo") I think things should
> work fine.
>
The patch that follows implements your suggested search order and
includes suggested Makefile changes.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* git-local-fetch and objects/info/alternates.
From: Tom Prince @ 2006-01-11 1:53 UTC (permalink / raw)
To: git
Is there some way to make git-local-fetch not try to copy files if the
source repository is in the destinations objects/info/alternates?
^ permalink raw reply
* Re: git-bisect is magical
From: walt @ 2006-01-11 1:50 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601101308540.4939@g5.osdl.org>
Linus Torvalds wrote:
[...]
> So when you say "git checkout origin", it actually _switches_ to the
> origin branch (which is just my state) and checks that out.
I think we are finally homing in on the very roots of my ignorance!
When you use the word 'switches' my eyes go glassy, just like when
my wife starts telling me everything I've done wrong today...
Please --> what am I switching *from* when I switch to 'origin'?
(Think: this guy is a total dumbshit! How can I possibly dumb-
down this basic knowledge any dumber?)
I know this is really bone-head-basic-stuff, but I'm quite sure
that this lies at the heart of my confusion.
When I finally understand this kindergarten material I can graduate
to first grade :o)
Thanks for your patience!
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Junio C Hamano @ 2006-01-11 0:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43C44CF2.5050808@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Johannes Schindelin wrote:
>> Wouldn't it make much more sense to have a switch in the Makefile,
>> which says *if* we have a libexec/ directory?
>
> No, it wouldn't, because then we can't use a different release of the
> git-tools without re-compiling the potty.
True, but *please* stop calling "git wrapper" a potty. It gives
me an impression that it is not connected to the plumbing.
I do not do Porcelain, but I do not do plastics nor glass either
;-).
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Junio C Hamano @ 2006-01-11 0:42 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Andreas Ericsson, git
In-Reply-To: <1136924980.11717.603.camel@brick.watson.ibm.com>
Michal Ostrowski <mostrows@watson.ibm.com> writes:
> How about searching for executables in the following places, and in this
> order:
>
> 1. --exec-path setting, if any
> 2. GIT_EXEC_PATH env var, if set
> 3. PATH (never modified)
> 4. Value of ${bindir} at build time
My preference is to first do this to the Makefile:
-- >8 --
diff --git a/Makefile b/Makefile
index 5817e86..b1e3055 100644
--- a/Makefile
+++ b/Makefile
@@ -71,6 +71,7 @@ ALL_LDFLAGS = $(LDFLAGS)
prefix = $(HOME)
bindir = $(prefix)/bin
+gitexecdir = $(prefix)/bin
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
@@ -144,7 +145,7 @@ PROGRAMS = \
git-describe$X
# what 'all' will build and 'install' will install.
-ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
+ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@@ -368,13 +369,13 @@ LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(ALL_PROGRAMS)
+all: $(ALL_PROGRAMS) git$X
all:
$(MAKE) -C templates
git$X: git.c $(LIB_FILE)
- $(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
+ $(CC) -DGIT_EXEC_PATH='"$(gitexecdir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
$(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -470,7 +471,9 @@ check:
install: all
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitexecdir))
+ $(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(gitexecdir))
+ $(INSTALL) git$X $(call shellquote,$(DESTDIR)$(bindir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
-- 8< --
and then make the rule for git things:
1. --exec-path
2. GIT_EXEC_PATH environment
3. $(gitexecdir)
in this order. Non git things should just use $PATH without
looking at anything else --- as long as a hook script calls a git
wrapper (i.e. "git foo" not "git-foo") I think things should
work fine.
> ... The patch I sent out this morning
> attempts to do this. (I'll append again to avoid confusion with
> previous patches)...
> + if (flags & RUN_GIT_CMD) {
> + execv_git_cmd(argv);
> + } else {
> + execvp(argv[0], (char *const*) argv);
> }
This bit sounds good, but if you were to go this route I'd
suggest to rename your exec_git_cmd() to execl_git_cmd() (and
terminate the vararg list with NULL) for naming consistency.
execv_git_cmd() is good---we do not *want* execvp_git_cmd(),
because we do not run git subcommand using PATH.
^ permalink raw reply related
* Re: git pull on Linux/ACPI release tree
From: Andreas Ericsson @ 2006-01-11 0:26 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90601101233h5def4840k315be9520796b5e@mail.gmail.com>
Martin Langhoff wrote:
> On 1/11/06, Adrian Bunk <bunk@stusta.de> wrote:
>
>>I am using the workaround of carrying the patches in a mail folder,
>>applying them in a batch, and not pulling from your tree between
>>applying a batch of patches and you pulling from my tree.
>
>
> In that case, there's a mostly automated way of doing that if you read
> the last couple lines of git-rebase, using something along the lines
> of
>
> git-format-patch <yours> <linus> | git-am -3 -k
>
Isn't this rebase in a nutshell ?
>
>>I'd say the main problem is that git with several other projects like
>>cogito and stg on top of it allow many different workflows. But finding
>>the one that suits one's needs without doing something in a wrong way
>>is non-trivial.
>
>
> You are right about that, but much of the space (of what workflows are
> interesting) is still being explored, and git and the porcelains
> reacting to people's interests. So it's still a moving target. A fast
> moving target.
>
Good thing there are competent people around to snipe those targets in
mid-stride. :)
I for one was amazed at how much easier git was to work with than any of
the other scm's I've tried (quite a few, I never really liked any of
them), and I really like the fact that it's flexible enough to suit
(almost) all our needs. The only thing I haven't really found it to be
satisfactory for is our collection of RPM spec-files and their
respective patches, where we not so much change files as continuously
replace them completely. Perhaps that's changed now that most
git-commands can be run from subdirs.
So, kudos to Linus for inventing it, Junio for nursing it, and the other
129 developers that have so far contributed to the current release.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Andreas Ericsson @ 2006-01-11 0:10 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0601102200040.31923@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>>>>>git programs exec other git programs, but they also exec non-git
>>>>>programs. I think it is not appropriate to change PATH (via
>>>>>prepend_to_path) because this may result in unexpected behavior when
>>>>>exec'ing non-git programs:
>>>>
>>>>This is a valid concern.
>>>
>>>Why? If what is prepended to PATH only contains git programs?
>>>
>>
>>
>>If git is installed with prefix=/usr, then that won't be the case.
>
>
> Okay, so here we have the problem: Two completely different setups. One
> into a standard location on the PATH (which used to be the default), the
> other with a libexec/ directory (which some want in the future). And a git
> wrapper which makes no difference between both.
>
> Wouldn't it make much more sense to have a switch in the Makefile, which
> says *if* we have a libexec/ directory?
No, it wouldn't, because then we can't use a different release of the
git-tools without re-compiling the potty.
void prepend_to_path(old_path, to_prep)
{
if (strstr(old_path, to_prep))
return;
really_prepend_to_path(old_path, to_prep);
}
would work just fine though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Andreas Ericsson @ 2006-01-11 0:06 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Junio C Hamano, git
In-Reply-To: <1136924980.11717.603.camel@brick.watson.ibm.com>
Michal Ostrowski wrote:
> On Tue, 2006-01-10 at 11:47 -0800, Junio C Hamano wrote:
>
>>
>>>Good point. Perhaps we should only prepend to path when the directory
>>>isn't already in $PATH, or append rather than prepend.
>>
>>I think appending not prepending would stop letting me say
>>
>> $ GIT_EXEC_PATH=/usr/libexec/git-core/0.99.9k git foo
>>
>>to try out older version, if I have more recent git in my PATH.
>>But I agree with Michal it is not nice to affect invocations of
>>"diff" (and things spawned from hooks, which would inherit PATH
>>from receive-pack).
>>
So how about prepending only when the directory isn't already in the
PATH? That can be done with a two-line patch to git.c only.
It will break the "diff in another dir" scenario in the highly unlikely
event that the other diff is located in the same dir as the git suite,
isn't supposed to be used, and the directory in question isn't in $PATH
already. People who have such a setup will be too ashamed to admit it,
so we're not likely to be blamed for it either. ;)
>>
>
>
> How about searching for executables in the following places, and in this
> order:
>
> 1. --exec-path setting, if any
> 2. GIT_EXEC_PATH env var, if set
> 3. PATH (never modified)
> 4. Value of ${bindir} at build time
>
This is more or less what's done today, with the exception that $PATH
isn't searched and it throws an error immediately no matter where
exec_path (the git.c variable) came from.
Adding $PATH to the search-pattern would be a simple matter of falling
back to execvp() if execve(), but then we could end up with running
programs from a different release while the user thinks he/she's
specifically running 1.0.3... Tricky problem, really.
>
> Secondly, the shell scripts as is cannot utilize this search order as
> long as they don't religiously use the git potty internally. If we were
> to "sed -e 's/git-/git /g' -i git*.sh" (grotesquely simplified of
> course) then they would.
>
I think this has been done, but as it happened to be convenient. I'd
prefer if the git potty could keep prepending the GIT_EXEC_PATH to the
path, really. We're bound to run into setup-related problems otherwise,
such as;
Alice writes a script that works fine for her and her friends, so she
shares it freely with Bob and whoever else might be listening. Bob's
git-tools aren't in the $PATH but he keeps the potty handy at all times.
He can't always run it through the potty because in some code-paths
Alice's script uses git-tools without going through the potty. Bob
thinks Alice puts entropy in her programs on purpose, so Alice flees,
sobbing and shaking in anger and betrayed trust. The two never speak again.
Luckily, Bruce Schneier shows up and saves the day.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] glossary: explain "master" and "origin"
From: walt @ 2006-01-10 23:33 UTC (permalink / raw)
To: git
In-Reply-To: <dq1cdd$rob$1@sea.gmane.org>
walt wrote:
> J. Bruce Fields wrote:
> [...]
>> Most projects have one upstream
>> project which they track. This is is the branch used for
>> tracking that project...
>
> s/This/'origin'/
>
> Lordy, I think many of the world's problems could be solved just
> by forbidding the use of pronouns entirely!
Now that I've had another beer, it occurs to me that a 'pronoun'
is nothing more or less than a 'pointer' to a noun.
Well! We all know that pointers are a major source of bugs in
C code. Is it possible that lint could be taught to detect
ambiguous pronouns in everyday speech?
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Alex Riesen @ 2006-01-10 22:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <86sls0498w.fsf@blue.stonehenge.com>
Randal L. Schwartz, Sat, Jan 07, 2006 11:34:23 +0100:
> >> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> So I'd prefer not touching for (@df) { print H "$_\n" } loops.
> >>
> >> Being as I'm a *bit* familiar with Perl, I'd write that as:
> >>
> >> print H "$_\0" for @deletedfiles;
> >>
>
> Alex> Does not work for old Perl
>
> Correct. It was added for Perl 5.5, first released on 22 July 1998.
>
> Are you really saying you need this code to run on Perl 5.4?
No, probably not. I definitely don't care, just wanted to point it
out as another one kind of a strange setup (as if activestat perl +
cygwin isn't enough...)
^ permalink raw reply
* Re: [PATCH] glossary: explain "master" and "origin"
From: walt @ 2006-01-10 22:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060110213645.GF13450@fieldses.org>
J. Bruce Fields wrote:
[...]
> Most projects have one upstream
> project which they track. This is is the branch used for
> tracking that project...
s/This/'origin'/
Lordy, I think many of the world's problems could be solved just
by forbidding the use of pronouns entirely!
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Alex Riesen @ 2006-01-10 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6dcl49x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sat, Jan 07, 2006 11:29:46 +0100:
> >>
> >> print H "$_\0" for @deletedfiles;
> >
> > Does not work for old Perl
>
> How old may I ask?
>
5.4, probably. I never seen it anymore. Was a standard installation of
some Solaris box.
^ permalink raw reply
* Re: [PATCH] stgit: typo fixes
From: Catalin Marinas @ 2006-01-10 21:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1136913240.2444.1.camel@dv>
On 10/01/06, Pavel Roskin <proski@gnu.org> wrote:
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Applied, thanks.
> - # if modes are the same (git-read-tree probably dealed with it)
> + # if modes are the same (git-read-tree probably dealt with it)
I think both are correct (at least in the UK).
--
Catalin
^ permalink raw reply
* Re: [PATCH] glossary: explain "master" and "origin"
From: Johannes Schindelin @ 2006-01-10 21:40 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, junkio
In-Reply-To: <20060110213645.GF13450@fieldses.org>
Hi,
On Tue, 10 Jan 2006, J. Bruce Fields wrote:
> On Tue, Jan 10, 2006 at 10:26:46PM +0100, Johannes Schindelin wrote:
> > +origin::
> > + The default upstream branch. Most projects have one upstream
> > + project which is tracked, and augmented with local changes which
> > + eventually get merged back. You never commit to this branch,
> > + unless you are maintaining the upstream project.
>
> The last line is somewhat confusing--a naive reader might take it to
> mean that as an upstream maintainer it would make sense to commit to a
> branch named "origin". How about something like this?
>
> "The default upstream branch. Most projects have one upstream
> project which they track. This is is the branch used for
> tracking that project. New updates from upstream will be
> fetched into this branch, but you should never commit to it
> yourself."
It is probably safer. Note: I actually commit to the origin branch in one
of my projects, and I follow it directly by a "git push origin".
Ciao,
Dscho
P.S.: I just noted that some of the tabs were turned into spaces. Does
asciidoc mind?
^ permalink raw reply
* Re: [PATCH] glossary: explain "master" and "origin"
From: J. Bruce Fields @ 2006-01-10 21:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0601102226130.649@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Jan 10, 2006 at 10:26:46PM +0100, Johannes Schindelin wrote:
> +origin::
> + The default upstream branch. Most projects have one upstream
> + project which is tracked, and augmented with local changes which
> + eventually get merged back. You never commit to this branch,
> + unless you are maintaining the upstream project.
The last line is somewhat confusing--a naive reader might take it to
mean that as an upstream maintainer it would make sense to commit to a
branch named "origin". How about something like this?
"The default upstream branch. Most projects have one upstream
project which they track. This is is the branch used for
tracking that project. New updates from upstream will be
fetched into this branch, but you should never commit to it
yourself."
--b.
^ permalink raw reply
* [PATCH] glossary: explain "master" and "origin"
From: Johannes Schindelin @ 2006-01-10 21:26 UTC (permalink / raw)
To: git, junkio
If you are a long time git user/developer, you forget that to a new git
user, these words have not the same meaning as to you.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/glossary.txt | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 2331be5..4ef7d2a 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -111,6 +111,17 @@ branch::
a particular revision, which is called the branch head. The
branch heads are stored in `$GIT_DIR/refs/heads/`.
+master::
+ The default branch. Whenever you create a git repository, a branch
+ named "master" is created, and becomes the active branch. In most
+ cases, this contains the local development.
+
+origin::
+ The default upstream branch. Most projects have one upstream
+ project which is tracked, and augmented with local changes which
+ eventually get merged back. You never commit to this branch,
+ unless you are maintaining the upstream project.
+
ref::
A 40-byte hex representation of a SHA1 pointing to a particular
object. These may be stored in `$GIT_DIR/refs/`.
^ permalink raw reply related
* Re: git-bisect is magical
From: Linus Torvalds @ 2006-01-10 21:17 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dq168p$3kt$1@sea.gmane.org>
On Tue, 10 Jan 2006, walt wrote:
>
> Just by stumbling around and trying things at random, I did a
> 'git-checkout origin' which *seemed* to resolve the merge-conflict,
> but left me feeling uneasy because I don't really understand what
> I'm doing. Can you give a short explanation of the difference
> between 'git reset --hard origin' and 'git-checkout origin'?
"git checkout" actually checks out a different branch (unless, to confuse
things, you ask it to just check out a specific _file_, in which case it
stays on the same branch).
So when you say "git checkout origin", it actually _switches_ to the
origin branch (which is just my state) and checks that out.
When you then do a "git pull", you'll just be pulling my newer state into
that older content branch, and it will resolve beautifully as a
fast-forward with no merge at all.
The downside with being in the "origin" branch is that if you now do any
kind of real development, you've now made "origin" mean something else
than it traditionally means - now it's no longer a branch tracking the
origin of your code, now it's an active development branch.
Do "git checkout master" to go back to where you used to be.
In contrast, a "git reset --hard origin" would have reset your _current_
branch to the state that the "origin" branch was in (and forced a checkout
of that exact state too - that's what the "--hard" flag means).
So when you say "git checkout origin", you should read it as "check out
the origin branch", and thus it makes perfect sense that "origin" now
becomes your current branch. In contrast, when you say "git reset --hard
origin", you should mentally read that as "reset the state of my current
tree to the same state as the origin branch".
The naming does make sense, but you just have to get used to what
"checkout" means (in its two different guises - checking out a file being
different from checking out a full tree) and what "reset" means.
> > An even better option is obviously to figure out _why_ that commit broke
> > for you in the first place, and get it fixed up-stream...
>
> I'm still waiting for the insulting email from the developer ;o) How
> long should I wait for a response before I start bugging other people?
Hey, send out the report to linux-kernel, and if it is a serious problem,
just cc me and Andrew (and whoever else seems to be most relevant for the
area: networking goes to David Miller, drivers mostly to Greg or Jeff etc
etc). Regardless, you should always cc at least the people who signed off
on the commit, since they want to know that they signed off on something
that turned out to be buggy.
Linus
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Junio C Hamano @ 2006-01-10 21:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michal Ostrowski, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0601102054200.27363@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Why? If what is prepended to PATH only contains git programs?
Recall the "diff" example Michal gave us.
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Johannes Schindelin @ 2006-01-10 21:03 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <1136925066.11717.605.camel@brick.watson.ibm.com>
Hi,
On Tue, 10 Jan 2006, Michal Ostrowski wrote:
> On Tue, 2006-01-10 at 20:55 +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 10 Jan 2006, Junio C Hamano wrote:
> >
> > > Michal Ostrowski <mostrows@watson.ibm.com> writes:
> > >
> > > > git programs exec other git programs, but they also exec non-git
> > > > programs. I think it is not appropriate to change PATH (via
> > > > prepend_to_path) because this may result in unexpected behavior when
> > > > exec'ing non-git programs:
> > >
> > > This is a valid concern.
> >
> > Why? If what is prepended to PATH only contains git programs?
> >
>
>
> If git is installed with prefix=/usr, then that won't be the case.
Okay, so here we have the problem: Two completely different setups. One
into a standard location on the PATH (which used to be the default), the
other with a libexec/ directory (which some want in the future). And a git
wrapper which makes no difference between both.
Wouldn't it make much more sense to have a switch in the Makefile, which
says *if* we have a libexec/ directory? This switch would decide if we
ever prepend the path with the libexec/ directory or not.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Johannes Schindelin @ 2006-01-10 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601101151090.4939@g5.osdl.org>
Hi,
On Tue, 10 Jan 2006, Linus Torvalds wrote:
> So having multiple bad commits is _never_ interesting.
Okay, I got it. A bug is supposed to be inherited by *all* its
descendants. Good.
I have to keep in mind that a commit is not actually a patch set, but can
be two or more (in case of a merge). So, a bug can be present in a
development line for a long, long time, but be visible only after a merge.
Since that commit can be compared to at least two trees, one of these
diffs must show the bug.
Thanks,
Dscho
^ permalink raw reply
* Re: git-bisect is magical
From: walt @ 2006-01-10 20:43 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601101143180.4939@g5.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 10 Jan 2006, Linus Torvalds wrote:
>> You can _undo_ the revert, so it's not permanent in that sense. Just do
>>
>> git reset --hard origin
>>
>> and your "master" branch will be forced back to the state that "origin"
>> was in.
>
> Btw, you can try this (careful - it will also undo any dirty state you
> have in your working tree), and then do the "pull" again (which should now
> be a trivial fast-forward) and then just try to do the "git revert" on the
> new state.
Just by stumbling around and trying things at random, I did a
'git-checkout origin' which *seemed* to resolve the merge-conflict,
but left me feeling uneasy because I don't really understand what
I'm doing. Can you give a short explanation of the difference
between 'git reset --hard origin' and 'git-checkout origin'?
> An even better option is obviously to figure out _why_ that commit broke
> for you in the first place, and get it fixed up-stream...
I'm still waiting for the insulting email from the developer ;o) How
long should I wait for a response before I start bugging other people?
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-10 20:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: Brown, Len, David S. Miller, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20060110201909.GB3911-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
On Tue, 10 Jan 2006, Adrian Bunk wrote:
>
> > Now, in this model, you're not really using git as a distributed system.
> > In this model, you're using git to track somebody elses tree, and track a
> > few patches on top of it, and then "git rebase" is a way to move the base
> > that you're tracking your patches against forwards..
>
> I am using the workaround of carrying the patches in a mail folder,
> applying them in a batch, and not pulling from your tree between
> applying a batch of patches and you pulling from my tree.
Yes, that also works.
I think "quilt" is really the right thing here, although stg may be even
easier due to the more direct git integration. But with a smallish number
of patches, just doing patch management by hand is obviously simply not a
huge problem either, so extra tools may just end up confusing the issue.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Martin Langhoff @ 2006-01-10 20:33 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Brown, Len, David S. Miller, linux-acpi,
linux-kernel, akpm, git
In-Reply-To: <20060110201909.GB3911@stusta.de>
On 1/11/06, Adrian Bunk <bunk@stusta.de> wrote:
> I am using the workaround of carrying the patches in a mail folder,
> applying them in a batch, and not pulling from your tree between
> applying a batch of patches and you pulling from my tree.
In that case, there's a mostly automated way of doing that if you read
the last couple lines of git-rebase, using something along the lines
of
git-format-patch <yours> <linus> | git-am -3 -k
> I'd say the main problem is that git with several other projects like
> cogito and stg on top of it allow many different workflows. But finding
> the one that suits one's needs without doing something in a wrong way
> is non-trivial.
You are right about that, but much of the space (of what workflows are
interesting) is still being explored, and git and the porcelains
reacting to people's interests. So it's still a moving target. A fast
moving target.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-10 20:32 UTC (permalink / raw)
To: Alex Riesen; +Cc: Andreas Ericsson, Junio C Hamano, git
In-Reply-To: <20060110201536.GA3155@steel.home>
On Tue, 2006-01-10 at 21:15 +0100, Alex Riesen wrote:
> Andreas Ericsson, Tue, Jan 10, 2006 20:13:34 +0100:
> > >My shell's rc-file doesn't get invoked when using ssh as a transport;
> > >that's part of the problem.
> >
> > It does for me and everybody else. $HOME/.bashrc is read even for
> > non-interactive shells. ...
On the system I'm dealing with, ssh does not invoke bash if a command is
specified.
If I do ssh user@system /home/user/bin/foo, ssh performs an exec
of /home/user/bin/foo; my shell is never invoked. This isn't up to me;
I don't have root on this system.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-10 20:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0601102054200.27363@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 2006-01-10 at 20:55 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 10 Jan 2006, Junio C Hamano wrote:
>
> > Michal Ostrowski <mostrows@watson.ibm.com> writes:
> >
> > > git programs exec other git programs, but they also exec non-git
> > > programs. I think it is not appropriate to change PATH (via
> > > prepend_to_path) because this may result in unexpected behavior when
> > > exec'ing non-git programs:
> >
> > This is a valid concern.
>
> Why? If what is prepended to PATH only contains git programs?
>
If git is installed with prefix=/usr, then that won't be the case.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox