* Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Schindelin @ 2007-11-28 23:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Wincent Colaiuta, Benoit Sigoure, Git Mailing List
In-Reply-To: <7vzlwy2dkm.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> It might be POSIX, but there are shells that do not like the
> >> expression 'export VAR=VAL'.
> >
> > As long as we have no positive report about any such shell that
> > _otherwise_ would be usable for git, why bother?
>
> I thought somebody already mention that ash mishandles "export VAR=VAL"
> but otherwise Ok.
I thought I read an implicit request from you. And yes, there was an
incidental bugfix in quiltimport.
Besides, this "why bother?" sounds awfully like "it's in POSIX and I
ignore the experience of Junio who knows that there are/were reasons not
to use export VAR=VAL" to me. After all, I read this often enough on this
list, and just forgot to fix it in filter-branch before submitting the
patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Schindelin @ 2007-11-28 23:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Wincent Colaiuta, Benoit Sigoure, Git Mailing List
In-Reply-To: <7vve7m2dhs.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Is there a particular reason to force linebreak when a semicolon would
> >> do?
> >
> > D'oh. Of course. You want me to resend?
>
> Semicolon I can handle but you seem to have local changes to filter
> branch.
Only that patch to de-uglify the functions in the commit filter that I
sent out earlier.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: David Kastrup @ 2007-11-28 23:10 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Wincent Colaiuta, Benoit Sigoure, Git Mailing List
In-Reply-To: <20071128230203.GA13964@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 28, 2007 at 11:53:13PM +0100, David Kastrup wrote:
>
>> dak@lola:~$ ash
>> $ export JUNK=woozle
>> $ sh -c 'echo $JUNK'
>> woozle
>> $ exit
>> dak@lola:~$ dash
>> $ export JUNK=woozle
>> $ sh -c 'echo $JUNK'
>> woozle
>> $ exit
>>
>> What problem are we talking about exactly, and with what shell?
>
> $ uname -sr
> FreeBSD 6.1-RELEASE-p17-jc1
> $ /bin/sh
> $ FOO='with spaces'
> $ echo $FOO
> with spaces
> $ OK=$FOO; export OK
> $ sh -c 'echo $OK'
> with spaces
> $ export BAD=$FOO
> $ sh -c 'echo $BAD'
> with
> $ echo $BAD
> with
I'd write
export BAD="$FOO"
anyhow. And also OK="$FOO" by the way. The alternatives scare me.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Johannes Schindelin @ 2007-11-28 23:12 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Junio C Hamano, Lars Hjemli, Steven Grimm, Linus Torvalds, git
In-Reply-To: <20071128224717.GG7376@fieldses.org>
Hi,
On Wed, 28 Nov 2007, J. Bruce Fields wrote:
> Would it be possible to add this to rebase instead of to pull?
>
> git rebase --url git://x.org/x.git master
>
> where --url means "interpret <upstream> as a branch from the given
> remote repository.
I was briefly considering it.
But the point is this: I know exactly if I want to rebase my branch onto
upstream, or if I want to merge it. There is not much point in mixing the
two.
So my rationale was: if we already have an existing framework to integrate
remote changes with our current branch, why not just go ahead and use it?
That's the reason BTW why I originally wanted a "rebase" merge stragegy.
Even if it is not technically a merge.
I really rather have no user-friendly support for fetch+rebase (and utter
a friendly, but loud curse everytime I made a "git pull" by mistake) than
yet another command.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Junio C Hamano @ 2007-11-28 23:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jan Hudec, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0711280036p33583824ge59af93bbe3f0a78@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On Nov 28, 2007 8:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> In case somebody is thinking about 36e5e70e0f40 (Start deprecating
>> "git-command" in favor of "git command"), that is a somewhat different
>> issue. What Linus suggested is not installing git-foo link for built-in
>> commands _anywhere_ on the filesystem. Not just "out of user's PATH".
>> That is not deprecating dash form but removing the support for it. We
>> need to give ample time for users to adjust to such a change.
>
> A little note on this one. I've been using git without builtin links
> for a while with my git-box port. There are still some builtin fixups
> needed. And because execv_git_cmd() always uses dash form, so it's
> impossible to use vanilla git without builtin links.
Thanks for a heads up.
Would people agree with a rough roadmap like this?
- v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
release notes for the version will warn users that:
(1) using git-foo from the command line, and
(2) using git-foo from your scripts without first prepending the
return value of "git --exec-path" to the PATH
is now officially deprecated (it has been deprecated for a long time
since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
the default configuration that does not install git-foo form in
user's PATH.
- Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming
for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.
- The release notes for v1.5.5 will warn users that git-foo will be
removed in v1.6.0 for many commands and it will be merely an accident
if some of them still work.
- Post v1.5.5, start cooking the change that does not install hardlinks
for built-in commands, aiming for inclusion in v1.6.0, by the end of
2008.
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Jan Hudec @ 2007-11-28 23:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0711281225150.27959@racer.site>
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
On Wed, Nov 28, 2007 at 12:32:10 +0000, Johannes Schindelin wrote:
> On Wed, 28 Nov 2007, Jakub Narebski wrote:
> > 4. If git-gui would use other language/toolkit, would you contribute?
> > Yes/No
>
> Yes, as long as it is a language/toolkit that is available on all
> platforms that I (have to) work. That pretty much excludes C# and Python
> as a language.
Out of interest, where does neither of those two work and Qt and tcl/tk do?
Mono and python both seem to be quite portable.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Junio C Hamano @ 2007-11-28 23:32 UTC (permalink / raw)
To: Johannes Schindelin
Cc: J. Bruce Fields, Lars Hjemli, Steven Grimm, Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0711282309030.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So my rationale was: if we already have an existing framework to integrate
> remote changes with our current branch, why not just go ahead and use it?
> That's the reason BTW why I originally wanted a "rebase" merge stragegy.
> Even if it is not technically a merge.
>
> I really rather have no user-friendly support for fetch+rebase (and utter
> a friendly, but loud curse everytime I made a "git pull" by mistake) than
> yet another command.
I suspect that people who do not like the two modes of checkout will
certainly not appreciate the overloading two behaviours to create
different kind of histories and two different ways to continue when the
integration do not go smoothly upon conflicts these two behaviours have.
However, I agree very much with an earlier comment made by Daniel about
our UI being task oriented instead of being command oriented, and I
actually consider it a good thing. So it does not bother me too much
that "git pull --rebase" has a quite different workflow from the regular
"merge" kind of pull.
So let's queue "pull --rebase" and see what happens.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-28 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <7vfxyq2c9b.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > On Nov 28, 2007 8:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >> In case somebody is thinking about 36e5e70e0f40 (Start deprecating
> >> "git-command" in favor of "git command"), that is a somewhat different
> >> issue. What Linus suggested is not installing git-foo link for built-in
> >> commands _anywhere_ on the filesystem. Not just "out of user's PATH".
> >> That is not deprecating dash form but removing the support for it. We
> >> need to give ample time for users to adjust to such a change.
> >
> > A little note on this one. I've been using git without builtin links
> > for a while with my git-box port. There are still some builtin fixups
> > needed. And because execv_git_cmd() always uses dash form, so it's
> > impossible to use vanilla git without builtin links.
>
> Thanks for a heads up.
>
> Would people agree with a rough roadmap like this?
>
> - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
> release notes for the version will warn users that:
>
> (1) using git-foo from the command line, and
>
> (2) using git-foo from your scripts without first prepending the
> return value of "git --exec-path" to the PATH
>
> is now officially deprecated (it has been deprecated for a long time
> since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
> the default configuration that does not install git-foo form in
> user's PATH.
Maybe we can squeeze a step in here where only porcelains are installed in
the bindir?
FWIW I think that we should fix the problem with the builtins being called
via their hard links. But how? As of now, libgit.a has no idea what the
builtins are; this information is buried in git.c.
The fundamental problem is that we cannot move handle_internal_command()
into libgit.a, because it has pointers to all builtin cmd_*() functions.
So maybe the best solution would be to try "git <command>" first, and then
"git-<command>"? But this means another exec() call :-(
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3] Allow update hooks to update refs on their own
From: Junio C Hamano @ 2007-11-28 23:42 UTC (permalink / raw)
To: Jeff King; +Cc: Steven Grimm, git
In-Reply-To: <20071128230355.GB13964@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 28, 2007 at 02:14:03PM -0800, Steven Grimm wrote:
>
>> @@ -177,7 +179,16 @@ static int receive_status(int in, struct ref *refs)
>>
>> line[strlen(line)-1] = '\0';
>> refname = line + 3;
>> - msg = strchr(refname, ' ');
>> + newsha1_hex = strchr(refname, ' ');
>> + if (newsha1_hex) {
>> + *newsha1_hex++ = '\0';
>> + if (get_sha1_hex(newsha1_hex, newsha1)) {
>> + fprintf(stderr, "protocol error: bad sha1 %s\n",
>> + newsha1_hex);
>> + newsha1_hex = NULL;
>> + }
>> + }
>> + msg = strchr(newsha1_hex, ' ');
>> if (msg)
>> *msg++ = '\0';
>
> Doesn't this always put the first "word" of a response into newsha1_hex?
> We want to do this only for 'ok' responses; 'ng' responses are already
> using that space as part of the error message.
I do not think reporting back the rewritten object name makes much sense
nor adds any value; it won't be useful information until you fetch the
object.
I do not think reporting back _anything_ other than "ok" adds much value
at all. Sure, if the update hook did something funky you would get such
a report, but the situation is not any different if some warm body is
sitting on the other end and building on top of what you pushed
immediately he sees any push into the repository, and in such a case
your git-push would not get any such reporting anyway.
We do not even have to worry about this reporting at all if we do not
allow munging the refs in the update hook. In a sense, this patch is
creating a problem that does not need to be solved. Perhaps modifying
update hook to allow so makes it possible to munge refs while holding a
lock, but is it really worth this hassle? Isn't there a better way, I
wonder?
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 23:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Karl Hasselström, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281600320.5349@iabervon.org>
On 11/28/07, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Wed, 28 Nov 2007, Jon Smirl wrote:
>
> > all my patches applied
> > git rebase
> > cursing.... I immediately knew what I had done
> > update stg and install it
> > stg repair
> > four of my 15 patches tried to apply, I received messages that there
> > were all empty
> > most stg commands won't work, they complain that the commit references
> > in the stg .git/* state are not correct.
> >
> > I then proceed to manually attempt repair.
>
> This sounds like the content of the applied patches got pulled into the
> non-stgit history of the branch it's working on, sort of like a stg commit
> except that stgit didn't know you'd done it. Then cleaning everything up
> from stgit's perspective caused all of those patches to become empty,
> since they were already applied in the base.
>
> I think fundamental issue you're having is that stgit is implementing the
> functionality of quilt using git's engine, not providing a version control
> system for patch series, which is what you really want. I've actually been
> working on a design for a git builtin for the idea that the patch series
> is your work product, and you want to version control that (additionally,
> you want to use git's engine to help with working on the series and
> represent it).
>
> Out of curiousity, are you using stgit as an integrator (with your work
> being keeping a collection of patches produced separately up-to-date) or
> as a patch developer (with your work being producing a state containing a
> single large new feature while maintaining this change as a series of
> self-contained patches)? I've been thinking primarily about the integrator
> task, in part because I've found it easy enough to do the developer task
> without anything other than current git. (That is, "git rebase -i" seems
> to work fine for making changes to a single logical patch series, all of
> whose patches are prepared locally and aren't independantly named in some
> particular fashion; the things that aren't handled are "I need to replace
> the pull of netdev.git with a new pull of netdev.git" or "I need to
> replace '[PATCH] fix-the-frobnozzle-gadget' with
> '[PATCH v2] fix-the-frobnozzle-gadget'.)
I'm a patch developer. You need to change the patches continuously to
track feedback on the lkml type lists. You also have to rebase in
order to keep tracking head. Other people often work on the same
things and this triggers merges against the pending patches.
Another class of problem is that I can write code a lot faster than I
can get it into the kernel. Currently I have 14 pending PPC patches
that I'm maintaining while I try and get a core change into the i2c
subsystem. All of the other patches depend on the core i2c patch.
Of course the version of the i2c patch that finally gets accepted will
probably cause me to have to rework the whole patch stack again.
stgit is what you need for this work flow. It lets me easily rebase or
edit specific patches. It also lets me easily maintain private debug
patches that I can apply as needed.
I'd just like for stgit to become a core part of git so that is can be
made more bullet proof. I'm losing my patch stack every couple of
weeks. It's normally a "user error" but it is way to easy to make
these user errors.
>
> The developer assist I'd actually like to see is: "I've got a single
> commit on top of a series of commits on top of an upstream commit; I want
> to distribute the changes made in the final commit to points in the series
> where the code that gets replaced (or context that gets inserted into) in
> the final commit gets introduced, with interactive stuff for sticking
> other hunks into particular commits or into new commits at some point in
> the series." That is, I want to do my revision of a patch series on the
> final commit of the series, and then have these changes distributed to the
> appropriate points, rather than doing work on intermediate states (unless
> what I'm fixing is stub code that gets replaced again in a later patch).
>
> -Daniel
> *This .sig left intentionally blank*
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Johannes Schindelin @ 2007-11-28 23:48 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <20071128232523.GE9174@efreet.light.src>
Hi,
On Thu, 29 Nov 2007, Jan Hudec wrote:
> On Wed, Nov 28, 2007 at 12:32:10 +0000, Johannes Schindelin wrote:
> > On Wed, 28 Nov 2007, Jakub Narebski wrote:
> > > 4. If git-gui would use other language/toolkit, would you
> > > contribute?
> > > Yes/No
> >
> > Yes, as long as it is a language/toolkit that is available on all
> > platforms that I (have to) work. That pretty much excludes C# and
> > Python as a language.
>
> Out of interest, where does neither of those two work and Qt and tcl/tk do?
> Mono and python both seem to be quite portable.
IRIX (an ancient one).
Besides, Mono is darned slow. Even Tcl/Tk is faster.
Furthermore, my complaint was not about a platform where neither C# nor
Python work. That is irrelevant. If you have one platform where only one
works, and another platform where only the other works, you cannot have a
single program for both platforms. Right?
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Junio C Hamano @ 2007-11-28 23:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0711282334250.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The fundamental problem is that we cannot move handle_internal_command()
> into libgit.a, because it has pointers to all builtin cmd_*() functions.
What's wrong with having cmd_* functions in the library to begin with?
^ permalink raw reply
* Re: Adding push configuration to .git/config
From: Johannes Schindelin @ 2007-11-28 23:50 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Steffen Prohaska, Junio C Hamano, git
In-Reply-To: <20071128221559.GC22395@denkbrett.schottelius.org>
Hi,
On Wed, 28 Nov 2007, Nico -telmich- Schottelius wrote:
> [branch "master"]
> merge = myremote
> push = myremote
> push = anotherremote
This is not how the current config works. "merge" specifies the remote
ref name, "remote" specifies the remote.
So your proposal would imply breaking most existing setups.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Junio C Hamano @ 2007-11-28 23:56 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <1195655278-19535-1-git-send-email-win@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> @@ -774,14 +774,14 @@ EOF
> }
>
> sub main_loop {
> - my @cmd = ([ 'status', \&status_cmd, ],
> - [ 'update', \&update_cmd, ],
> - [ 'revert', \&revert_cmd, ],
> - [ 'add untracked', \&add_untracked_cmd, ],
> - [ 'patch', \&patch_update_cmd, ],
> - [ 'diff', \&diff_cmd, ],
> - [ 'quit', \&quit_cmd, ],
> - [ 'help', \&help_cmd, ],
> + my @cmd = ([ 'status', \&status_cmd, '[s]tatus', ],
> + [ 'update', \&update_cmd, '[u]date', ],
> + [ 'revert', \&revert_cmd, '[r]evert', ],
> + [ 'add untracked', \&add_untracked_cmd, '[a]dd untracked', ],
> + [ 'patch', \&patch_update_cmd, '[p]atch', ],
> + [ 'diff', \&diff_cmd, '[d]iff', ],
> + [ 'quit', \&quit_cmd, '[q]uit', ],
> + [ 'help', \&help_cmd, '[h]elp', ],
> );
I like the general idea of making it more obvious that you can use the
unique prefix, but I think you should make list_and_choose do this
automatically without adding a redundant element in the command array.
If you do so, the same highlighting will automatically appear when you
are picking which paths to update in the update subcommand, for example.
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: J. Bruce Fields @ 2007-11-28 23:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Lars Hjemli, Steven Grimm, Linus Torvalds,
git
In-Reply-To: <7v1waa2bfi.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 28, 2007 at 03:32:49PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So my rationale was: if we already have an existing framework to integrate
> > remote changes with our current branch, why not just go ahead and use it?
> > That's the reason BTW why I originally wanted a "rebase" merge stragegy.
> > Even if it is not technically a merge.
> >
> > I really rather have no user-friendly support for fetch+rebase (and utter
> > a friendly, but loud curse everytime I made a "git pull" by mistake) than
> > yet another command.
>
> I suspect that people who do not like the two modes of checkout will
> certainly not appreciate the overloading two behaviours to create
> different kind of histories and two different ways to continue when the
> integration do not go smoothly upon conflicts these two behaviours have.
>
> However, I agree very much with an earlier comment made by Daniel about
> our UI being task oriented instead of being command oriented, and I
> actually consider it a good thing. So it does not bother me too much
> that "git pull --rebase" has a quite different workflow from the regular
> "merge" kind of pull.
>
> So let's queue "pull --rebase" and see what happens.
What I'm really most worried about isn't the commandline switch but the
config option--it makes the same commandlines silently behave in very
different ways.
I really don't want every tutorial that mentions "git pull" to have to
say "the following applies only if git.<current-branch>.rebase is
false". And it'll be either that or risk having a lot of people saying
"I typed in exactly that commandline, but this happened....".
A default to "false" does at least require positive acknowledgement, but
if this is expected to be used by newbies, they're going to be told to
set that config before they understand the difference it makes.
--b.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-29 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <7vr6ia0w4i.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The fundamental problem is that we cannot move
> > handle_internal_command() into libgit.a, because it has pointers to
> > all builtin cmd_*() functions.
>
> What's wrong with having cmd_* functions in the library to begin with?
I was considering it not desirable (after all, the library is meant to
have common functions in it), but you're right...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Junio C Hamano @ 2007-11-29 0:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071121171235.GA32233@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> There are a few add-on questions:
>
> - should typechanges in both directions be used, or just file ->
> symlink?
>
> - this actually produces a 'copied' status rather than a 'renamed'
> since the 'foo' entry does still exist. Is this reasonable?
I do not think this is a risky change; it won't add too many rename
sources we did not consider traditionally (typechanges are usually rare
event anyway).
You are copying the source to elsewhere and then completely rewriting it
(even making it into a different type), so I do not think 'copied' is so
unreasonable. An alternative would be to say you renamed it and then
created something totally different, which would also be reasonable.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jakub Narebski @ 2007-11-29 0:14 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0711280036p33583824ge59af93bbe3f0a78@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On Nov 28, 2007 8:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> In case somebody is thinking about 36e5e70e0f40 (Start deprecating
>> "git-command" in favor of "git command"), that is a somewhat different
>> issue. What Linus suggested is not installing git-foo link for built-in
>> commands _anywhere_ on the filesystem. Not just "out of user's PATH".
>> That is not deprecating dash form but removing the support for it. We
>> need to give ample time for users to adjust to such a change.
>
> A little note on this one. I've been using git without builtin links
> for a while with my git-box port. There are still some builtin fixups
> needed. And because execv_git_cmd() always uses dash form, so it's
> impossible to use vanilla git without builtin links.
By the way, what is the status of your git-box port?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] scripts: do not get confused with HEAD in work tree
From: Junio C Hamano @ 2007-11-29 0:15 UTC (permalink / raw)
To: git
When you have a file called HEAD in your work tree, many commands that
our scripts feed "HEAD" to would complain about the rev vs path
ambiguity. A solution is to form command line more carefully by
appending -- to them, which makes it clear that we mean HEAD rev not
HEAD file.
This patch would apply to maint.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 8 ++++----
git-filter-branch.sh | 2 +-
git-merge-ours.sh | 2 +-
git-rebase--interactive.sh | 4 ++--
git-rebase.sh | 4 ++--
git-stash.sh | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 32c46d7..5792631 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -214,7 +214,7 @@ fi
case "$resolved" in
'')
- files=$(git diff-index --cached --name-only HEAD) || exit
+ files=$(git diff-index --cached --name-only HEAD --) || exit
if [ "$files" ]; then
echo "Dirty index: cannot apply patches (dirty: $files)" >&2
exit 1
@@ -348,7 +348,7 @@ do
case "$resolved$interactive" in
tt)
# This is used only for interactive view option.
- git diff-index -p --cached HEAD >"$dotest/patch"
+ git diff-index -p --cached HEAD -- >"$dotest/patch"
;;
esac
esac
@@ -409,7 +409,7 @@ do
# trust what the user has in the index file and the
# working tree.
resolved=
- git diff-index --quiet --cached HEAD && {
+ git diff-index --quiet --cached HEAD -- && {
echo "No changes - did you forget to use 'git add'?"
stop_here_user_resolve $this
}
@@ -431,7 +431,7 @@ do
then
# Applying the patch to an earlier tree and merging the
# result may have produced the same tree as ours.
- git diff-index --quiet --cached HEAD && {
+ git diff-index --quiet --cached HEAD -- && {
echo No changes -- Patch already applied.
go_next
continue
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ffcc408..dbab1a9 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -95,7 +95,7 @@ USAGE="[--env-filter <command>] [--tree-filter <command>] \
. git-sh-setup
git diff-files --quiet &&
- git diff-index --cached --quiet HEAD ||
+ git diff-index --cached --quiet HEAD -- ||
die "Cannot rewrite branch(es) with a dirty working directory."
tempdir=.git-rewrite
diff --git a/git-merge-ours.sh b/git-merge-ours.sh
index c81a790..29dba4b 100755
--- a/git-merge-ours.sh
+++ b/git-merge-ours.sh
@@ -9,6 +9,6 @@
# because the current index is what we will be committing as the
# merge result.
-git diff-index --quiet --cached HEAD || exit 2
+git diff-index --quiet --cached HEAD -- || exit 2
exit 0
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index d65df2c..ff38a22 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -52,7 +52,7 @@ require_clean_work_tree () {
git rev-parse --verify HEAD > /dev/null &&
git update-index --refresh &&
git diff-files --quiet &&
- git diff-index --cached --quiet HEAD ||
+ git diff-index --cached --quiet HEAD -- ||
die "Working tree is dirty"
}
@@ -331,7 +331,7 @@ do
git rev-parse --verify HEAD > /dev/null &&
git update-index --refresh &&
git diff-files --quiet &&
- ! git diff-index --cached --quiet HEAD &&
+ ! git diff-index --cached --quiet HEAD -- &&
. "$DOTEST"/author-script &&
export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
git commit -F "$DOTEST"/message -e
diff --git a/git-rebase.sh b/git-rebase.sh
index b0c8ac1..c9b284c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -60,7 +60,7 @@ continue_merge () {
fi
cmt=`cat "$dotest/current"`
- if ! git diff-index --quiet HEAD
+ if ! git diff-index --quiet HEAD --
then
if ! git-commit -C "$cmt"
then
@@ -253,7 +253,7 @@ fi
# The tree must be really really clean.
git update-index --refresh || exit
-diff=$(git diff-index --cached --name-status -r HEAD)
+diff=$(git diff-index --cached --name-status -r HEAD --)
case "$diff" in
?*) echo "cannot rebase: your index is not up-to-date"
echo "$diff"
diff --git a/git-stash.sh b/git-stash.sh
index 5bbda47..77c9421 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -14,7 +14,7 @@ trap 'rm -f "$TMP-*"' 0
ref_stash=refs/stash
no_changes () {
- git diff-index --quiet --cached HEAD &&
+ git diff-index --quiet --cached HEAD -- &&
git diff-files --quiet
}
^ permalink raw reply related
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Johannes Schindelin @ 2007-11-29 0:16 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Junio C Hamano, Lars Hjemli, Steven Grimm, Linus Torvalds, git
In-Reply-To: <20071128235633.GI7376@fieldses.org>
Hi,
On Wed, 28 Nov 2007, J. Bruce Fields wrote:
> On Wed, Nov 28, 2007 at 03:32:49PM -0800, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > So my rationale was: if we already have an existing framework to integrate
> > > remote changes with our current branch, why not just go ahead and use it?
> > > That's the reason BTW why I originally wanted a "rebase" merge stragegy.
> > > Even if it is not technically a merge.
> > >
> > > I really rather have no user-friendly support for fetch+rebase (and utter
> > > a friendly, but loud curse everytime I made a "git pull" by mistake) than
> > > yet another command.
> >
> > I suspect that people who do not like the two modes of checkout will
> > certainly not appreciate the overloading two behaviours to create
> > different kind of histories and two different ways to continue when the
> > integration do not go smoothly upon conflicts these two behaviours have.
> >
> > However, I agree very much with an earlier comment made by Daniel about
> > our UI being task oriented instead of being command oriented, and I
> > actually consider it a good thing. So it does not bother me too much
> > that "git pull --rebase" has a quite different workflow from the regular
> > "merge" kind of pull.
> >
> > So let's queue "pull --rebase" and see what happens.
>
> What I'm really most worried about isn't the commandline switch but the
> config option--it makes the same commandlines silently behave in very
> different ways.
>
> I really don't want every tutorial that mentions "git pull" to have to
> say "the following applies only if git.<current-branch>.rebase is
> false". And it'll be either that or risk having a lot of people saying
> "I typed in exactly that commandline, but this happened....".
>
> A default to "false" does at least require positive acknowledgement, but
> if this is expected to be used by newbies, they're going to be told to
> set that config before they understand the difference it makes.
Hey, why not just special case "mergeOptions = rebaseInstead"?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: give rerere a chance
From: Junio C Hamano @ 2007-11-29 0:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711221117590.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> @@ -166,13 +167,13 @@ pick_one_preserving_merges () {
> msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
> # No point in merging the first parent, that's HEAD
> new_parents=${new_parents# $first_parent}
> - # NEEDSWORK: give rerere a chance
> if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> output git merge $STRATEGY -m "$msg" \
> $new_parents
> then
> + git rerere
This comment is not about this rerere change, but output is a shell
function and I vaguely recall we had a discussion on "VAR=VAL cmd" form
of single-shot export not working for them as expected...
^ permalink raw reply
* Re: [PATCH] rebase -i: give rerere a chance
From: Johannes Schindelin @ 2007-11-29 0:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ik129d4.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > @@ -166,13 +167,13 @@ pick_one_preserving_merges () {
> > msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
> > # No point in merging the first parent, that's HEAD
> > new_parents=${new_parents# $first_parent}
> > - # NEEDSWORK: give rerere a chance
> > if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> > GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> > GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> > output git merge $STRATEGY -m "$msg" \
> > $new_parents
> > then
> > + git rerere
>
> This comment is not about this rerere change, but output is a shell
> function and I vaguely recall we had a discussion on "VAR=VAL cmd" form
> of single-shot export not working for them as expected...
Hmm. What do you propose? In the long run, I _want_ to have rebase as a
builtin, which would solve this problem, probably. But in the short run?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Junio C Hamano @ 2007-11-29 0:24 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <1195809174-28142-1-git-send-email-mfwitten@mit.edu>
Michael Witten <mfwitten@mit.edu> writes:
> git-cvsserver just did the following:
> (1) run hooks/update
> (2) commit if hooks/update passed
>
> This commit simply adds:
> (3) run hooks/post-receive
>
> Also, there are a few grammar cleanups and
> consistency improvements.
I gave only a very cursory look; looks Ok to me. This makes me wonder
if post-update wants to run as well.
What do other people who run git-cvsserver think?
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Junio C Hamano @ 2007-11-29 0:37 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: gitster, git
In-Reply-To: <1196205847-22968-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> diff --git a/setup.c b/setup.c
> index f512ea0..ffc30bf 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -7,6 +7,25 @@ static int inside_work_tree = -1;
> const char *prefix_path(const char *prefix, int len, const char *path)
> {
> const char *orig = path;
> + const char *work_tree = get_git_work_tree();
> + if (is_absolute_path(path) && work_tree) {
Could you structure this part to read like this, into a separate
function:
static const char *strip_work_tree_path(const char *prefix, int len, const char *path)
{
...
}
const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
if (is_absolute_path(path))
path = strip_work_tree_path(prefix, len, path);
...
About the part that would be moved out of line with such a
restructuring,
> + int n = strlen(work_tree);
> + if (!strncmp(path, work_tree, n) && (path[n] == '/' || !path[n])) {
> + if (path[n])
> + path += n + 1;
> + else
> + path += n;
> +
> + if (prefix && !strncmp(path, prefix, len - 1)) {
> + if (path[len - 1] == '/')
> + path += len;
> + else
> + if (!path[len - 1])
> + path += len - 1;
> + }
This makes me wonder what happens if after stripping the worktree path
path does not match the prefix.
^ permalink raw reply
* Re: [PATCH 3/3] cvsimport: miscellaneous packed-ref fixes
From: Junio C Hamano @ 2007-11-29 0:52 UTC (permalink / raw)
To: Jeff King; +Cc: Emanuele Giaquinta, git
In-Reply-To: <20071128185628.GC11320@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> @@ -998,7 +996,7 @@ if ($orig_branch) {
> $orig_branch = "master";
> print "DONE; creating $orig_branch branch\n" if $opt_v;
> system("git-update-ref", "refs/heads/master", "$remote/$opt_o")
> - unless -f "$git_dir/refs/heads/master";
> + defined get_headref('refs/heads/master');
Where did the unless go ;-)?
Thanks, queued.
^ 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