* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nicolas Pitre @ 2006-11-29 18:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7vr6vmsnly.fsf@assigned-by-dhcp.cox.net>
On Tue, 28 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > This argument has its converse. What you should _not_ have to worry
> > about all the time is whether your index really includes all the changes
> > you want included in your next commit.
>
> That's what we have "git diff" with various output options for;
> I often do "git diff --stat" or "git diff --name-status" when I
> know I am about to commit in a dirty working tree. I suspect
> that I am not getting your point.
I'm afraid this conversation is getting nowhere then.
> > And whether wanting to leave local changes in the working directory
> > without commiting them actually happen more often than wanting to commit
> > every changes is arguable.
>
> I do not think anybody is talking about which happens more
> often.
But I do.
> "screw the index" people do not have to worry about the
> index during the course of their changes in the working tree
> toward the next commit, and the only time they need to tell git
> (which _IS_ a system based on the index, dammit) about what they
> want to do with the index is at the commit time, and they tell
> git to "screw the index" by passing "-a" to "git commit".
No one talked about "screw the index" people. Those are happily using
Cogito.
We're talking about flattening the GIT learning curve. And as futile it
may seem to you that newbies should just use "commit -a" without
thinking, they still get bothered by that -a there. And probably
they'll forget about it once in a while and then GIT will _appear_ as
malfunctioning to them.
Of course amongst those newbies that didn't went away at this point
there will be those who decide to study further and come to the index
concept. And I hope that we all agree that the index is a powerful but
still advanced concept that should not be presented up front.
But my point is: why not making a very little change to the default
commit behavior. Really little change involving -a being the default.
The impact on newbies will be significant as they won't have to grok
everything at once to make sense of this -a we are telling them to use
blindly. And it will sort of match known expectations to commit
everything dirty.
And actually my point above is that in many cases, maybe the majoryty of
those case but this is arguable, what one is doing is not keeping dirty
and uncommited state around but rather committing every changes all the
time. In _that_ case, which might not be all the time but often enough,
then using -a is annoying[1].
So having -a the default makes GIT much more friendly to new users. You
"add" files, you "commit", you edit some files, you "commit" again, and
everything works fine, and you are happy and starts feeling good about
GIT.
Now for those who've seen the light and want to use the index it is not
much of a bother to add a -i to their commit invokation. At this point
if you understand the index you know what you're doing, and using -i
won't bother you as much it bothered you to use -a without knowing
why when you was a newbie.
But still, if you are a GIT old fart and have difficulties switching
habits, or if you simply are the kind with dirty not-to-commit state in
your tree and adding -i all the time bothers you just like [1] above,
then there is a way out! You are a GIT expert at this point of course
and certainly know how to add an alias for the -i to be implicit with
your "commit".
Therefore I think this is much more logical to ask the experts to add an
alias for "commit -i" than asking such tricks from less experienced
users. This is all my point is about.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Jakub Narebski @ 2006-11-29 18:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611291234350.9647@xanadu.home>
Nicolas Pitre wrote:
> But my point is: why not making a very little change to the default
> commit behavior. Really little change involving -a being the default.
> The impact on newbies will be significant as they won't have to grok
> everything at once to make sense of this -a we are telling them to use
> blindly. And it will sort of match known expectations to commit
> everything dirty.
>
> And actually my point above is that in many cases, maybe the majoryty of
> those case but this is arguable, what one is doing is not keeping dirty
> and uncommited state around but rather committing every changes all the
> time. In _that_ case, which might not be all the time but often enough,
> then using -a is annoying[1].
>
> So having -a the default makes GIT much more friendly to new users. You
> "add" files, you "commit", you edit some files, you "commit" again, and
> everything works fine, and you are happy and starts feeling good about
> GIT.
>
> Now for those who've seen the light and want to use the index it is not
> much of a bother to add a -i to their commit invokation. At this point
> if you understand the index you know what you're doing, and using -i
> won't bother you as much it bothered you to use -a without knowing
> why when you was a newbie.
>
> But still, if you are a GIT old fart and have difficulties switching
> habits, or if you simply are the kind with dirty not-to-commit state in
> your tree and adding -i all the time bothers you just like [1] above,
> then there is a way out! You are a GIT expert at this point of course
> and certainly know how to add an alias for the -i to be implicit with
> your "commit".
>
> Therefore I think this is much more logical to ask the experts to add an
> alias for "commit -i" than asking such tricks from less experienced
> users. This is all my point is about.
But for different reasons this alias cannot be named "commit". So you cannot
with alias make "git commit" (with -a by default) work with index.
If "git commit -a" by default heresy ;-) was accepted, I'd rather it be via
configuration option.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-blame: handling of revisions and filenames
From: Junio C Hamano @ 2006-11-29 18:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20061115215225.GA4595@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> And I afraid the patch has a small chance of crashing: I don't check
> if there is enough space in argv (don't actually even know how to),
Actually this is a safe thing to do because we already know (and
removed) the "path" argument from the command line at that
point. If the original command line did not have "path" we have
already rejected it. So unk at that point never exceeds argc.
> diff --git a/builtin-blame.c b/builtin-blame.c
> index 066dee7..83c8905 100644
> --- a/builtin-blame.c
> +++ b/builtin-blame.c
> @@ -1787,6 +1787,7 @@ int cmd_blame(int argc, const char **arg
> /* Now we got rev and path. We do not want the path pruning
> * but we may want "bottom" processing.
> */
> + argv[unk++] = "--";
> argv[unk] = NULL;
>
> init_revisions(&revs, NULL);
Thanks.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Junio C Hamano @ 2006-11-29 18:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611291234350.9647@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Of course amongst those newbies that didn't went away at this point
> there will be those who decide to study further and come to the index
> concept. And I hope that we all agree that the index is a powerful but
> still advanced concept that should not be presented up front.
I do not necessarily agree with the last sentence.
> But my point is: why not making a very little change to the default
> commit behavior. Really little change involving -a being the default.
While I understand that is what you are suggesting, my point is
that it will not stop at "commit -a". I already gave an example
that "diff" needs to behave differently, if you want to match
the behaviour of git consistently with "newbie" expectations.
If you go down that path, you would end up with two systems
named git, that base their operations on two quite different
mental models and behave differently. You do not want to go
there; well at least I don't.
> The impact on newbies will be significant as they won't have to grok
> everything at once to make sense of this -a we are telling them to use
> blindly.
So don't tell them to use "-a" blindly. Teach them what it
means using the terms they understand; we assume they haven't
learned the "index" yet, so we would explain that "it is a way
to commit all changes in the working tree". It is a short-hand
so that they do not have to list all modified paths (or their
git is recent enough, ".").
After they learn what it means and get used to using it, they
will start wondering why we do not default to "-a". By that
time, they would already have learned the config (because the
first thing the tutorial teaches is user.name/user.email), and
can use the alias mechanismk there to alias -a away.
^ permalink raw reply
* Re: git and bzr
From: Marko Macek @ 2006-11-29 18:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicholas Allen, Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0611290922410.3513@woody.osdl.org>
Linus Torvalds wrote:
> So most of the time, when you use git, you can ignore the index. It's
> really important, and it's used _all_ the time, but you can still mostly
> ignore it. But when handling a merge conflict, the index is really what
> sets git apart, and what really helps a LOT.
Actually, people (at least me) dislike the index because in the most common
operations (status, diff, commit), they have to know that the command doesn't actually
display all their work but just the 'indexed' part of it.
For people used to cvs, svn and other systems it would be nicer if diff -a
and commit -a (and possibly other commands) were the default.
index is of course necessary during merging, ... and as a speed optimization
for applying patches when you know the working copy is clean.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Steven Grimm @ 2006-11-29 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vzmaaozi8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> After they learn what it means and get used to using it, they
> will start wondering why we do not default to "-a".
More likely they will start wondering the instant you tell them to use
it the first time. Or at least they'll ask, "If '-a' means commit all
files, what's the default?" And then you either have to blow off the
question or start telling them about the index.
-Steve
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Steven Grimm @ 2006-11-29 19:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekkir2$6fq$1@sea.gmane.org>
Jakub Narebski wrote:
> If "git commit -a" by default heresy ;-) was accepted, I'd rather it be via
> configuration option.
>
So the newbie-friendly behavior should require learning how to edit a
configuration file, and the expert-friendly behavior should be the one
you get on your first out-of-the-box exposure to git?
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Jakub Narebski @ 2006-11-29 19:30 UTC (permalink / raw)
To: git
In-Reply-To: <456DDB91.8080608@midwinter.com>
Steven Grimm wrote:
> Jakub Narebski wrote:
>>
>> If "git commit -a" by default heresy ;-) was accepted, I'd rather it be via
>> configuration option.
>
> So the newbie-friendly behavior should require learning how to edit a
> configuration file, and the expert-friendly behavior should be the one
> you get on your first out-of-the-box exposure to git?
Well, newbie friendly could be the default, while hacker friendly
(expert friendly) would require learning how to configure git
(there is actually no need to hand-edit configuration file, by the way).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-11-29 20:00 UTC (permalink / raw)
To: git
In-Reply-To: <20061129160355.GF18810@admingilde.org>
On Wednesday 2006, November 29 16:03, Martin Waitz wrote:
> The way I wanted to address this is to show in the supermodule
> git-status that the submodule is using another branch.
> That way you are warned and can decide not to commit the supermodule.
The problem I see with tracking a particular branch is that it makes it less
convenient to use git's quick-branching features in the submodules. Let's
say I want to try something out quickly in a submodule, I make a branch,
commit, commit, "hmm, looks good, let's snapshot it in the supermodule", make
a supermodule branch, "oh no, I've got to tell the supermodule to track the
new (but temporary) branch in the submodule do a commit, switch the submodule
branch back to master, delete the temporary branch, remember that the
supermodule is tracking that branch and tell the supermodule to track
something else instead... It all seems too complicated to me.
> Pro HEAD:
> - update-index on submodule really updates the supermodule index with
> a commit that resembles the working directory.
Ouch. Why does the submodule need to update the supermodule index? That
should be done by update-index in the supermodule. Further, how is the
supermodule index going to represent working directory changes in the
submodule? The only link between the two is a commit hash. It has to be
like that otherwise you haven't made a supermodule-submodule, you've just
made one super-repository. Also, if you don't store submodule commit hashes,
then there is no way to guarantee that you're going to be able get back the
state of the submodule again.
> Contra HEAD:
> - HEAD is not garanteed to be equal to the working directory anyway,
> you may have uncommitted changes.
That's the case for every file in a repository, so isn't really a worry. It's
the equivalent of changing a file and not updating the index - who cares? As
long as update-index tells you that the submodule is dirty and what to do to
clean it, everything is great.
> - when updating the supermodule, you have to take care that your
> submodules are on the right branch.
> You might for example have some testing-throwawy branch in one
> submodule and don't want to merge it with other changes yet.
What is the "right" branch though? As I said above, if you're tracking one
branch in the submodule then you've effectively locked that submodule to that
branch for all supermodule uses. Or you've made yourself a big rod to beat
yourself with everytime you want to do some development on an "off" branch on
the submodule.
> Pro refs/heads/master:
> - the supermodule really tracks one defined branch of development.
Why is this a pro?
> - you can easily overwrite one submodule by changing to another branch,
> without fearing that changes in the supermodule change anything
> there.
You can always do that anyway by simply not running update-index for the
submodule in the supermodule.
> Contra refs/heads/master:
> - after updating the supermodule, you may not have the correct working
> directory checked out everywhere, because some submodules may be on a
> different branch.
This seems like the biggest problem to me - doesn't this negate all the
advantages of a submodule system? After a check in, you have no idea if what
you checked in was what was in your working tree.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git and bzr
From: Johannes Schindelin @ 2006-11-29 20:07 UTC (permalink / raw)
To: Marko Macek
Cc: Linus Torvalds, Nicholas Allen, Jakub Narebski, bazaar-ng, git
In-Reply-To: <456DD76C.4010902@gmx.net>
Hi,
On Wed, 29 Nov 2006, Marko Macek wrote:
> Linus Torvalds wrote:
> > So most of the time, when you use git, you can ignore the index. It's
> > really important, and it's used _all_ the time, but you can still
> > mostly ignore it. But when handling a merge conflict, the index is
> > really what sets git apart, and what really helps a LOT.
>
> Actually, people (at least me) dislike the index because in the most
> common operations (status, diff, commit), they have to know that the
> command doesn't actually display all their work but just the 'indexed'
> part of it.
No. It does display all your work.
However, as Linus pointed out, if there are automatically merged entries
without conflicts, it will not display them. Which is sane!
And yes, you can hide some modifications by putting the modified file into
the index. But then you did that very much on purpose.
> For people used to cvs, svn and other systems it would be nicer if diff
> -a and commit -a (and possibly other commands) were the default.
And what exactly do you think is happening when "cvs add" and "svn add"
did _not_ really add the file to the repository, but only a subsequent
"commit" does?
> index is of course necessary during merging, ... and as a speed
> optimization for applying patches when you know the working copy is
> clean.
I think that it is one major achievement of git to make clear and sane
definitions of branches (which are really just pointers
into the revision graph), and the index (which is the staging area).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Johannes Schindelin @ 2006-11-29 20:01 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <456DDADC.7030509@midwinter.com>
Hi,
On Wed, 29 Nov 2006, Steven Grimm wrote:
> Junio C Hamano wrote:
> > After they learn what it means and get used to using it, they
> > will start wondering why we do not default to "-a".
>
> More likely they will start wondering the instant you tell them to use
> it the first time. Or at least they'll ask, "If '-a' means commit all
> files, what's the default?" And then you either have to blow off the
> question or start telling them about the index.
So what? Tell them that there is a staging area, which makes many
operations of git very powerful and fast. And this staging area is called
"the index" in git. And to put some files into it, specify those
files. If you want _all_ modified files there, use "-a". That's it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Junio C Hamano @ 2006-11-29 20:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Nicolas Pitre, Steven Grimm
In-Reply-To: <Pine.LNX.4.63.0611292059480.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 29 Nov 2006, Steven Grimm wrote:
>
>> More likely they will start wondering the instant you tell them to use
>> it the first time. Or at least they'll ask, "If '-a' means commit all
>> files, what's the default?" And then you either have to blow off the
>> question or start telling them about the index.
>
> So what? Tell them that there is a staging area, which makes many
> operations of git very powerful and fast. And this staging area is called
> "the index" in git. And to put some files into it, specify those
> files. If you want _all_ modified files there, use "-a". That's it.
Well said.
I think I have stated my preference and reasoning clearly enough
on this topic, so I won't waste my time repeating them. My time
is better spent on _listening_ to people who might want to make
convincing arguments to influence what I will end up deciding
(the final decision will be mine anyway).
By the way, I've been having fun with the xdl_merge() stuff;
thanks for a job well done. I will push some of it out in 'pu'
shortly.
^ permalink raw reply
* Re: git and bzr
From: Jon Loeliger @ 2006-11-29 20:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nicholas Allen, Linus Torvalds, Jakub Narebski, bazaar-ng,
Git List
In-Reply-To: <Pine.LNX.4.63.0611291145510.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Wed, 2006-11-29 at 04:49, Johannes Schindelin wrote:
> As for your scenario: There really should be a "what to do when my merge
> screwed up?" document.
I have a few examples scenarios and some notes on
cleaning up after failed merges in my slides from
the presentation I did at OLS last summer.
Feel free to look at it off of www.jdl.com!
jdl
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-29 20:45 UTC (permalink / raw)
To: Marko Macek; +Cc: git, bazaar-ng
In-Reply-To: <456DD76C.4010902@gmx.net>
On Wed, 29 Nov 2006, Marko Macek wrote:
>
> Actually, people (at least me) dislike the index because in the most common
> operations (status, diff, commit), they have to know that the command doesn't
> actually display all their work but just the 'indexed' part of it.
I don't see your point, really.
Nothing forces you to change the index. None of the normal operations do
that, for example, and you really have to _explicitly_ ask git to update
the index for you.
So you can really think of it as a better list of names than what CVS and
others maintain for you. It's exactly the same as the CVS "Entries" file,
except it's got capabilities that CVS will never have - tracking not just
the filename, but the merge status, the permissions, and the actual
contents of an entry.
And by default, and in the absense of any failed merges, you will _never_
see any of those extra capabilities.
> For people used to cvs, svn and other systems it would be nicer if diff -a
> and commit -a (and possibly other commands) were the default.
Why? I mean really.. Why do people mind the index? If you've not done
anything to explicitly update it, and you just write "git commit", it will
tell you exactly which files are dirty, which files are untracked, and
then say "nothing to commit".
Maybe we shouldn't even say "use git-update-index to mark for commit", we
should just say "use 'git commit -a' to mark for commit", but the point
is, there really is no downside. So you forget to mention which files to
commit, what's the downside really? It tells you what is up, and you can
just mention the files explicitly, or use "-a" to say "ok, commit
everything that is dirty", and it doesn't really get any simpler than
that.
And the ADVANTAGES of the index are legion. You may not appreciate them
initially, but the disadvantages people talk about really don't exist in
real life, and once you actually start doing merges with conflicts, and
fix things up one file at a time (and perhaps take a break and do
something else before you come back to the rest of the conflicts), the
index saves your sorry ass, and is a _huge_ advantage.
Similarly, it _allows_ you to do things that just a list of files never
allows you to. You don't _have_ to use it to mark individual files as
being ready to be committed, but you _can_. It's nothing that you need to
know or worry about if you're not aware of the index, but it's a
capability that is there for when you're willing to go there.
So there really isn't any true disadvantage. Most of the people who are
afraid of the index have probably never actually used it, and have never
even had a _reason_ to use it. They're nervous just because they know it
exists, and don't know what it does. But you can just ignore it.
So get over your fears, and just ignore it, and things will be fine.
Linus
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-29 20:49 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marko Macek, Linus Torvalds, Nicholas Allen, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0611292101420.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
> On Wed, 29 Nov 2006, Marko Macek wrote:
>>
>> index is of course necessary during merging, ... and as a speed
>> optimization for applying patches when you know the working copy is
>> clean.
>
> I think that it is one major achievement of git to make clear and sane
> definitions of branches (which are really just pointers
> into the revision graph), and the index (which is the staging area).
Something resembling index is needed anyway: 1) for "commit all changed
files" to prepare list of files to commit, excluding ignored files,
2) to mark files as "to be added" or "to be removed" (well, git index
could be a little bit smarter here in marking "intent to add"), 3) as
a place for doing the merging. Git just doesn't hide it.
I agree that git definition of branches, and git not hiding index is
it's advantage... and disadvantage to those who learned using version
control on other SCM.
--
Jakub Narebski
^ permalink raw reply
* Re: gitk with arguments fails on OSX
From: Junio C Hamano @ 2006-11-29 20:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Randal L. Schwartz
In-Reply-To: <86vekyw9ue.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> Johannes> Hi,
> Johannes> On Wed, 29 Nov 2006, Randal L. Schwartz wrote:
>
>>>
>>> Using the native "wish", gitk fails on OSX 10.4 if given any arguments.
>>> For example, the failure for "gitk --all" is:
>>>
>>> localhost.local:~/MIRROR/git-GIT % gitk --all
>>> Error in startup script: unknown option "-state"
>>> while executing
>
> Johannes> Known problem:
>
> Johannes> http://thread.gmane.org/gmane.comp.version-control.git/31266/focus=31266
>
> The fix works for me. How about mainlining it?
The changes look sane to me.
Paul? I prefer to be fed gitk changes through you, if you don't
mind.
> From: Randal L. Schwartz <merlyn@localhost.local>
> Date: Wed, 29 Nov 2006 07:20:04 -0800
> Subject: [PATCH] patch from mailing list
>
> ---
> gitk | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gitk b/gitk
> index ab383b3..d9df0a3 100755
> --- a/gitk
> +++ b/gitk
> @@ -1632,8 +1632,8 @@ proc showview {n} {
>
> set curview $n
> set selectedview $n
> - .bar.view entryconf 2 -state [expr {$n == 0? "disabled": "normal"}]
> - .bar.view entryconf 3 -state [expr {$n == 0? "disabled": "normal"}]
> + .bar.view entryconf "Edit*" -state [expr {$n == 0? "disabled": "normal"}]
> + .bar.view entryconf "Delete*" -state [expr {$n == 0? "disabled": "normal"}]
>
> if {![info exists viewdata($n)]} {
> set pending_select $selid
> @@ -6305,8 +6305,8 @@ if {$cmdline_files ne {} || $revtreeargs ne {}} {
> set viewargs(1) $revtreeargs
> set viewperm(1) 0
> addviewmenu 1
> - .bar.view entryconf 2 -state normal
> - .bar.view entryconf 3 -state normal
> + .bar.view entryconf "Edit*" -state normal
> + .bar.view entryconf "Delete*" -state normal
> }
>
> if {[info exists permviews]} {
> --
> 1.4.4.1.gf927
>
>
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] rename_ref: use lstat(2) when testing for symlink
From: Lars Hjemli @ 2006-11-29 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The current check for symlinked reflogs was based on stat(2), which is
utterly embarrassing.
Fix it, and add a matching testcase.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
This is on top of my previous [RFC], which is kind of strange, but I hope
it wasn't dropped on the floor...
refs.c | 2 +-
t/t3200-branch.sh | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 479f18c..d8c19e6 100644
--- a/refs.c
+++ b/refs.c
@@ -792,7 +792,7 @@ int rename_ref(const char *oldref, const char *newref)
struct ref_lock *lock;
char msg[PATH_MAX*2 + 100];
struct stat loginfo;
- int log = !stat(git_path("logs/%s", oldref), &loginfo);
+ int log = !lstat(git_path("logs/%s", oldref), &loginfo);
if (S_ISLNK(loginfo.st_mode))
return error("reflog for %s is a symlink", oldref);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index afaa853..5782c30 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -104,4 +104,11 @@ test_expect_success \
git-branch -m s/s s &&
test -f .git/logs/refs/heads/s'
+test_expect_failure \
+ 'git-branch -m u v should fail when the reflog for u is a symlink' \
+ 'git-branch -l u &&
+ mv .git/logs/refs/heads/u real-u &&
+ ln -s real-u .git/logs/refs/heads/u &&
+ git-branch -m u v'
+
test_done
--
1.4.4.1.gf0df
^ permalink raw reply related
* Re: gitk with arguments fails on OSX
From: Paul Mackerras @ 2006-11-29 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Randal L. Schwartz
In-Reply-To: <7vejrmou75.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> The changes look sane to me.
>
> Paul? I prefer to be fed gitk changes through you, if you don't
> mind.
I just pushed a somewhat more comprehensive fix to my gitk.git repo on
master.kernel.org. (Actually I had checked it in some time ago
locally but forgot to do the push, sorry.)
Regards,
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Jon Loeliger @ 2006-11-29 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7v1wnr19do.fsf@assigned-by-dhcp.cox.net>
On Sat, 2006-11-25 at 15:53, Junio C Hamano wrote:
> I am not sure if 'merge in corresponding branch' is the only
> valid workflow, however. I am reluctant to make the system
> automatically do so if the solution makes other workflows more
> painful to follow. Automatically merging remotes/origin/$foo
> when on $foo branch is not good enough, in other words (also,
> there may be a hierarchy under remotes/ other than origin). It
> might make sense to introduce "Merge: " in remotes/ file and if
> they are present use "Pull: " only to decide what are fetched
> and use "Merge: " to decide what is merged (if we were doing the
> system from scratch, the former would have been named "Fetch: "
> but it is too late now).
Heh. It was too late back here too!
From: Jon Loeliger <jdl@freescale.com>
To: Git List <git@vger.kernel.org>
Subject: Re: GIT 0.99.7d, and end of week status.
Date: Mon, 26 Sep 2005 15:17:32 -0500
Message-Id: <1127765852.5735.36.camel@cashmere.sps.mot.com>
jdl
^ permalink raw reply
* xdl_merge(), was Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Johannes Schindelin @ 2006-11-29 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkluoulf.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 29 Nov 2006, Junio C Hamano wrote:
> By the way, I've been having fun with the xdl_merge() stuff; thanks for
> a job well done. I will push some of it out in 'pu' shortly.
Oh *blush*, I fixed a few things since I sent that out... Will submit the
remaining things as soon as the beast shows up in pu.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] pack-objects: remove redundent status information
From: Nicolas Pitre @ 2006-11-29 22:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The final 'nr_result' and 'written' values must always be the same
otherwise we're in deep trouble. So let's remove a redundent report.
And for paranoia sake let's make sure those two variables are actually
equal after all objects are written (one never knows).
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 753bcd5..a2dc7d1 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -514,6 +514,8 @@ static void write_pack_file(void)
if (do_progress)
fputc('\n', stderr);
done:
+ if (written != nr_result)
+ die("wrote %d objects while expecting %d", written, nr_result);
sha1close(f, pack_file_sha1, 1);
}
@@ -1662,7 +1664,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
}
}
if (progress)
- fprintf(stderr, "Total %d, written %d (delta %d), reused %d (delta %d)\n",
- nr_result, written, written_delta, reused, reused_delta);
+ fprintf(stderr, "Total %d (delta %d), reused %d (delta %d)\n",
+ written, written_delta, reused, reused_delta);
return 0;
^ permalink raw reply related
* [PATCH 1/4] xdl_merge(): set mode to 0 when refining conflicts
From: Johannes Schindelin @ 2006-11-29 23:23 UTC (permalink / raw)
To: Davide Libenzi, git, junkio
mode == 0 means "conflict", and just because a conflict has been
split does not mean that the latter half is no conflict.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
xdiff/xmerge.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 04f2795..7b85aa5 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -228,6 +228,7 @@ static int xdl_refine_conflicts(xdfenv_t
m2->next = m->next;
m->next = m2;
m = m2;
+ m->mode = 0;
m->i1 = xscr->i1 + i1;
m->chg1 = xscr->chg1;
m->i2 = xscr->i2 + i2;
--
1.4.4.g5aac-dirty
^ permalink raw reply related
* [PATCH 2/4] xdl_merge(): do return number of conflicts
From: Johannes Schindelin @ 2006-11-29 23:24 UTC (permalink / raw)
To: Davide Libenzi, git; +Cc: junkio
If no error occurred during merge, xdl_merge() is supposed to return
the number of conflicts.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
xdiff/xmerge.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 7b85aa5..6b6fbb8 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -384,6 +384,7 @@ int xdl_merge(mmfile_t *orig, mmfile_t *
xpparam_t const *xpp, int level, mmbuffer_t *result) {
xdchange_t *xscr1, *xscr2;
xdfenv_t xe1, xe2;
+ int ret = 0;
result->ptr = NULL;
result->size = 0;
@@ -413,9 +414,9 @@ int xdl_merge(mmfile_t *orig, mmfile_t *
result->ptr = xdl_malloc(mf1->size);
memcpy(result->ptr, mf1->ptr, mf1->size);
result->size = mf1->size;
- } else if (xdl_do_merge(&xe1, xscr1, name1,
+ } else if ((ret = xdl_do_merge(&xe1, xscr1, name1,
&xe2, xscr2, name2,
- level, xpp, result) < 0) {
+ level, xpp, result)) < 0) {
xdl_free_script(xscr1);
xdl_free_script(xscr2);
xdl_free_env(&xe1);
@@ -428,6 +429,6 @@ int xdl_merge(mmfile_t *orig, mmfile_t *
xdl_free_env(&xe1);
xdl_free_env(&xe2);
- return 0;
+ return ret;
}
--
1.4.4.g5aac-dirty
^ permalink raw reply related
* [PATCH 3/4] xdl_merge(): fix an off-by-one bug
From: Johannes Schindelin @ 2006-11-29 23:24 UTC (permalink / raw)
To: Davide Libenzi, git; +Cc: junkio
The line range is i1 .. (i1 + chg1 - 1), not i1 .. (i1 + chg1).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
xdiff/xmerge.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 6b6fbb8..9fe2059 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -194,11 +194,11 @@ static int xdl_refine_conflicts(xdfenv_t
* we have a very simple mmfile structure.
*/
t1.ptr = (char *)xe1->xdf2.recs[m->i1]->ptr;
- t1.size = xe1->xdf2.recs[m->i1 + m->chg1]->ptr
- + xe1->xdf2.recs[m->i1 + m->chg1]->size - t1.ptr;
- t2.ptr = (char *)xe2->xdf2.recs[m->i1]->ptr;
- t2.size = xe2->xdf2.recs[m->i1 + m->chg1]->ptr
- + xe2->xdf2.recs[m->i1 + m->chg1]->size - t2.ptr;
+ t1.size = xe1->xdf2.recs[m->i1 + m->chg1 - 1]->ptr
+ + xe1->xdf2.recs[m->i1 + m->chg1 - 1]->size - t1.ptr;
+ t2.ptr = (char *)xe2->xdf2.recs[m->i2]->ptr;
+ t2.size = xe2->xdf2.recs[m->i2 + m->chg2 - 1]->ptr
+ + xe2->xdf2.recs[m->i2 + m->chg2 - 1]->size - t2.ptr;
if (xdl_do_diff(&t1, &t2, xpp, &xe) < 0)
return -1;
if (xdl_change_compact(&xe.xdf1, &xe.xdf2, xpp->flags) < 0 ||
--
1.4.4.g5aac-dirty
^ permalink raw reply related
* [PATCH 4/4] xdl_merge(): fix thinko
From: Johannes Schindelin @ 2006-11-29 23:25 UTC (permalink / raw)
To: Davide Libenzi, git; +Cc: junkio
If one side's block (of changed lines) ends later than the other
side's block, the former should be tested against the next block
of the other side, not vice versa.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
xdiff/xmerge.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 9fe2059..6d4f9b6 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -318,13 +318,13 @@ static int xdl_do_merge(xdfenv_t *xe1, x
xscr1->i1 = i2;
xscr1->i2 += xscr1->chg2;
xscr1->chg2 = 0;
- xscr1 = xscr1->next;
+ xscr2 = xscr2->next;
} else if (i2 > i1) {
xscr2->chg1 -= i2 - i1;
xscr2->i1 = i1;
xscr2->i2 += xscr2->chg2;
xscr2->chg2 = 0;
- xscr2 = xscr2->next;
+ xscr1 = xscr1->next;
} else {
xscr1 = xscr1->next;
xscr2 = xscr2->next;
--
1.4.4.g5aac-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox