* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Linus Torvalds @ 2006-12-01 2:44 UTC (permalink / raw)
To: Carl Worth
Cc: Junio C Hamano, Nicolas Pitre, Theodore Tso, Andreas Ericsson,
Johannes Schindelin, git
In-Reply-To: <87y7psfjvk.wl%cworth@cworth.org>
On Thu, 30 Nov 2006, Carl Worth wrote:
>
> What I'm trying to say is that the _defaults_ are not well geared
> toward helping new users do what they want to with git.
I really think we're better off just telling people how things work (with
practical examples, and _not_ by trying to explain things at too high a
conceptual level).
I don't think people generally are all that stupid, and I think it's
actually counter-productive to try to basically lie about how things work.
It will just make it harder for people later.
> One thing you never really answered was my conversation with a new
> user that left the user with the impression of "git is bizarre". How
> can I fix that conversation?
I really _think_ that a lot of that is in the documentation being overly
technically oriented and talking often about the technical side of how
things work in the index, rather than the purely user side of what that
_results_ in.
I really believe that people can understand the concept of "git add"
squirrelling away the whole state of the file at add-time, and suddenly
it's not all that complicated. Also, it's not even something that people
really need to worry about, and I think we should make that more clear.
In other words, the documentation could _literally_ give the example of
git add file.c
.. change file.c ..
git commit
git diff file.c
and talk about this issue up-front, but then just say outright to people
that "if you don't want to know about these details, you can always just
use 'git commit -a', and you'll never really even notice".
There really isn't all that much to "hide". I think we've sometimes done a
horrible job on _presentation_, but I also think that it's better to give
examples of thigns like this, and then tell people not to worry, because
they'll never need to care unless they actually start doing something
fancy.
So all your examples of "badness" aren't really all that bad. Newbies
should be told:
- use "git commit -a" normally (with pointers on fancier usage)
- and yes, we obviously should change the message to say "git commit -a"
instead of "git update-index"
- do NOT use the "-m" flag, and look at what git tells you in the
commit message!
This is actually important, because even for non-newbie users, the git
commit message for a conflicting merge contains useful information,
and people should read it. It lists the conflicting filenames for a
reason, namely so that you can talk about what the conflicts in
question _were_.
[ Btw, I can't stress that last point enough. Using the "-m" flag should
really really REALLY be discouraged. It is almost always a horrible
mistake, not just because it means that you miss what git will tell you
about which files are getting checked in, but because it invariably
leads to bad single-line commit messages.
In my personal opinion, the "-m" flag is really only good for scripts
and sending example git sequences to each other, ie it's there for
automated "do this" kind of scripting, and using it for real work should
be a castration offence, so that you don't perpetuate your genes.
(I've seen _way_ too many projects where there's a lot of "update
version" one-liner commit messages. Damn, I can understand that in CVS,
where the logs are useless _anyway_, but in git it shouldn't be
allowed!). ]
Ok, with that rant out of the way, my _point_ is that we're actually much
better off educating users about _why_ git is different, than trying to
lie to them and say "it's just like CVS by default, but when you're a real
man, we'll show you how you can rock your world".
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Carl Worth @ 2006-12-01 3:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Nicolas Pitre, Theodore Tso, Andreas Ericsson,
Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0611301827540.3451@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 5147 bytes --]
On Thu, 30 Nov 2006 18:44:41 -0800 (PST), Linus Torvalds wrote:
> I really think we're better off just telling people how things work (with
> practical examples, and _not_ by trying to explain things at too high a
> conceptual level).
>
> I don't think people generally are all that stupid, and I think it's
> actually counter-productive to try to basically lie about how things work.
> It will just make it harder for people later.
Sure. There's no need to lie to about how things work. And I agree
that would cause later problems. As far as getting the message out, we
have several different ways to do that:
1. In-person presentations, demos, tutorials
2. Written tutorials
3. Reference documentation
4. Output from git commands
5. The default behavior of git commands
And that list is roughly sorted from most to least "information
bandwidth". The limited bandwidth at the bottom-most levels in my
list, (together with the fact that people often start trying the tool
at only those levels), means we have to be even that much more careful
about the messaging there.
In my experience, I think we succeed quite well at level 1. In person,
we get immediate feedback from the user and it's easy to catch and
cut-off any user confusion up-front. "Oh, you don't even need to run
that command...use this instead", etc.
As for the other levels, you hit on most of them in your comments:
> I really _think_ that a lot of that is in the documentation being overly
> technically oriented and talking often about the technical side of how
> things work in the index, rather than the purely user side of what that
> _results_ in.
Yes, this is a big problem at level 3. Things like the "man git-diff"
scare factor that Ted pointed out. So let's work to fix all of that.
> I really believe that people can understand the concept of "git add"
> squirrelling away the whole state of the file at add-time, and suddenly
> it's not all that complicated. Also, it's not even something that people
> really need to worry about, and I think we should make that more clear.
One trick with saying "we just need to document this better" to avoid
the confusion is that approach assumes that the users are actually
_reading_ the right documentation. Now, we're currently making this
harder than it should be at level 4 by doing things like sending users
to the documentation for update-index. But still, if we can make
things less surprising in some cases _without_ needing the
documentation, then we make it that much easier.
> In other words, the documentation could _literally_ give the example of
>
> git add file.c
> .. change file.c ..
> git commit
> git diff file.c
>
> and talk about this issue up-front,
Yes, adding lots of good examples to the written documentation will
help, (anyone that reads it at least).
> that "if you don't want to know about these details, you can always just
> use 'git commit -a', and you'll never really even notice".
...
> - use "git commit -a" normally (with pointers on fancier usage)
...
> - and yes, we obviously should change the message to say "git commit -a"
> instead of "git update-index"
So here you're arguing for documenting the heck out of "commit -a" at
all of levels 1-4. If we're going to do that, why not just go the next
tiny step and make it work as "git commit" by default, (which people
_will_ try). If we can say, "come from hg or bzr and things will just
work", people can try that, be satisfied that git isn't bizarre, and
then we can teach where git's actually superior.
> - do NOT use the "-m" flag, and look at what git tells you in the
> commit message!
Interesting. I do use -m almost exclusively. I do that for speed I
think, (but I do do multi-line commit messages). The only drawback I
was aware of was that I'm doing manual word wrapping, but I might
start trying this to see information in the commit message, (instead
I've been checking first with "git diff --cached").
> Ok, with that rant out of the way, my _point_ is that we're actually much
> better off educating users about _why_ git is different, than trying to
> lie to them and say "it's just like CVS by default, but when you're a real
> man, we'll show you how you can rock your world".
I still don't see any lie here. If we all agree that "git commit -a"
is the most commonly desired form, it's what users expect by default
(based on _any_ other system they might be coming from), and we agree
we need to mention it a lot more at every level of the
documentation---given all that, why do we insist on having something
else be the default?
Because it gives us an opportunity to teach about the power of the
index to anyone that gets confused and complains? That strategy
ignores everyone that gets confused and just leaves without talking to
us.
I'm talking about changing the default of what "git commit" does, yes,
but it can still be documented honestly as to what it really does and
why. It would fit in just fine with Nico's new documentation for "git
add" for example, and "git diff" doesn't need to be changed at all,
(but it's documentation should be made much less scary).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Michael K. Edwards @ 2006-12-01 3:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carl Worth, Junio C Hamano, Nicolas Pitre, Theodore Tso,
Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0611301827540.3451@woody.osdl.org>
I think Linus is right that the semantics of "git commit" and "git
add" are not broken and do not need fixing. But Carl and others are
right that they are not self-explanatory to most people, whether or
not they have been tainted by CVS and its ilk. Maybe this is a job
for a little contextual documentation (aka hand-holding) to accompany
the tutorial and reference docs.
How about we add a set of "expert" flags in the config, gating access
to non-intuitive behavior and to idioms that should be discouraged in
casual use. For instance, with an empty config, "git commit -m" fails
with a message to the effect of:
"As a general rule, you shouldn't use the -m flag unless you're
scripting git for automation purposes. If this is what you are doing,
or if you insist on committing without feedback about the state of
your tree, you need to set the 'expert-commit-message' flag".
Likewise, when your working copy does not match HEAD, "git commit"
with neither -a nor an explicit list of files fails, saying:
"'git commit' on a dirty working copy does the Right Thing! But
some people find the Right Thing counter-intuitive at first. Either
stick to 'git commit -a' or read the docs and set the
'expert-commit-dirty' flag."
And "git add" still does the right thing, but warns:
"Remember, git is not CVS. 'git add' has taken a snapshot of the
current _contents_ of the newly added files, not just their names.
From now on, you will need to 'git mark' edits to them if you want
them to be part of the next commit, just like edits to files that have
already been committed. This warning can be suppressed by setting the
'expert-add-content' flag."
Note that 'expert-commit', etc. should NOT change the semantics of any
command that doesn't error out. They should just enable idioms that a
novice user is likely to try and get unexpected results. They should
be overridable from the environment, of course, either one by one
(export GIT_EXPERT_COMMIT_MESSAGE=y) or wholesale (export
GIT_I_GROK_IN_FULLNESS_UP_TO=1.4.4).
Cheers,
^ permalink raw reply
* Diffs from CVS keyword expansion
From: Jon Smirl @ 2006-12-01 3:56 UTC (permalink / raw)
To: Git Mailing List
Anyone have a nice script for suppressing diffs caused by CVS keyword
expansion when someone checked the kernel sources into CVS?
I have 200,000 lines of various forms of this mixed in with real changes
It is unclear who checked it into CVS, Microcross or Arch Linux. If it
is Arch Linux finding the source for their 2.6.11.4-1 release would
help a lot. I looked on their web site and couldn't locate it.
I'm starting understand why the support for MX21 on a CSB535FS has
never been added to the mainline.
diff --git a/drivers/char/ftape/lowlevel/ftape-ctl.c
b/drivers/char/ftape/lowlevel/ftape-ctl.c
index 32e0439..ff10633 100644
--- a/drivers/char/ftape/lowlevel/ftape-ctl.c
+++ b/drivers/char/ftape/lowlevel/ftape-ctl.c
@@ -17,9 +17,9 @@
the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
*
- * $Source: /homes/cvs/ftape-stacked/ftape/lowlevel/ftape-ctl.c,v $
- * $Revision: 1.4 $
- * $Date: 1997/11/11 14:37:44 $
+ * $Source: /home/arch-linux/{cvs}/linux--dev--2.6/drivers/char/ftape/lowlevel/ftape-ctl.c,v
$
+ * $Revision: 1.1.1.1 $
+ * $Date: 2005/03/24 06:16:39 $
*
* This file contains the non-read/write ftape functions for the
* QIC-40/80/3010/3020 floppy-tape driver "ftape" for Linux.
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 63c8168..54d9a10 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
- * $Id: ipoib_main.c 1377 2004-12-23 19:57:12Z roland $
+ * $Id: ipoib_main.c,v 1.1.1.1 2005/03/24 06:16:41 arch-linux Exp $
*/
#include "ipoib.h"
--
Jon Smirl
^ permalink raw reply related
* Re: [RFC] git-add update with all-0 object
From: Theodore Tso @ 2006-12-01 4:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0611301749450.20138@iabervon.org>
On Thu, Nov 30, 2006 at 07:12:31PM -0500, Daniel Barkalow wrote:
> This is where I think "git add" is really broken. For every other git
> command, if the command causes the index to not match HEAD, the command
> contains "index" either in the name of the command or in an option.
>
> So, if you understand the index, and you understand git's model, but you
> don't know this one weird corner case, you will come to the conclusion
> that "git add <path>" leaves <path> such that the index matches HEAD.
But it's not just this one wierd corner case. You yourself said that
"git pull/merge" leave the index where it's != HEAD.
I have serious trouble believing that "if the command leaves index !=
HEAD, the command must contain 'index' in either the name of the
command or the option" is all that important of a consistent rule or
principle that must be maintained at all costs.
By the way, after thinking about this for a while, part of the problem
is that the name "index" really sucks. Which is perhaps why Linus is
now trying to stop us from actually using the term "index" in these
discussions. :-) If we called it a "staging area", as our Great
Leader has suggested, I think it would be a lot easier for novice
users to understand. Consider what is in the git man page:
The index is a simple binary file, which contains an efficient
representation of a virtual directory content at some random
time. It does so by a simple array that associates a set of
names, dates, permissions and content (aka "blob") objects
together. The cache is always kept ordered by name, and names
are unique (with a few very specific rules) at any point in
time, but the cache has no long-term meaning, and can be
partially updated at any time.....
In particular, the index file can have the representation of
an intermediate tree that has not yet been instantiated. So
the index can be thought of as a write-back cache, which can
contain dirty information that has not yet been written back
to the backing store.
For a kernel programmer, this might not be understandable --- but for
your typical application programmer, this is enough to cause him or
her to conclude that git is simply not meant for use by mere mortals.
So as Junio and Linus have both said, it's all about your mental
model, and if we think about it in terms of a staging area for a
commit, and we think about what commands are most natural given that
model, it's far more important than whether a command has "index" in
its name or specified in an option.
Put another way, the reason why I think people are liking the whole
"git add" and "git rm" suggestion is that it's a nice middle ground
between the "hide the index" and the "shove the index in the user's
face" approaches. It's not that we are hiding the fact that there is
this thing with the horribly chosen name "index", but instead we talk
about this concept of a staging area and we don't dwell on things like
the fact that it is a binary file which stores an efficient
representation of a virtual directory.... blah blah blah.
Once this is done, the only command which is still problematic to
describe is "git diff". Yes, it almost always does the right thing.
But if you read the man page, even we are now using "<tree-ish>"
instead of "<ent>" to describe it, it still forces the user who is
reading the man page to prove to him- or her-self that it really
always does the right thing. The EXAMPLES section really helps, but
even so, the man page is need in terrible of help.
For example, exactly what "git diff" does is described in terms of
"git diff-files", "git diff-index". and "git diff-tree". (And the
command name git-diff-index, git-diff-tree and git-diff-files in the
DESCRIPTION aren't even hotlinks, making it hard to get to the
plumbing man pages, which is the only place where you can get
documentation of the options accepted by git-diff.)
OK, so once the novice user gets past this hurdle, he/she says, OK,
what does "git diff <tree-ish>" does? Hmm, according to EXAMPLES,
this diffs the working tree with the named tree. What options can I
give? Well, with one one <tree-ish>, I have to go to read the man
page for "git-diff-index", whose synposis says, "Compares content and
mode of blobs between the index and repository". But wait! According
to git-diff's EXAMLES section, "git diff <tree-ish>" doesn't involve
the index at all! Why does the synposis say anything about the index?
And this leaves the novice confused and bewildered. And why not? If
the user spends time puzzling through the man page, he/she will
discover that:
1) "git diff-index <tree>" compares the tree with the working
directory, and doesn't involve the index at all, even though it is in
the command name. WTF?!?
2) If you want to really diff the index, you have to use the command
"git diff-index --cached <tree>"
If you look at this from the point of the novice user, it becomes very
clear why the index and commands that operate on the index are
hopelessly confusing. Yes, if you the grasshopper read and medidate
very deeply the low-level meaning of the plumbing, and then someone
like Linus slaps you upside the head with one of his e-mail messages,
it will suddenly make sense to you. The problem with this method is
that it doesn't scale terribly well. :-)
But if you are just reading the "git-diff" man page for the first
time, and are then forced to read the "git-diff-index" man page to
puzzle out what a particular "git diff" option does, and then have to
confront the notion that something as "git diff HEAD" involves a
command "git diff-index", even though this confusing thing called the
index is never involved unless the --cache option is given --- can you
see how this might cause the beginning user of git to conclude that
git is hopelessly confusing and too hard to use?
The question then is how can we fix the "git diff" man page, and how
do we explain "git diff" in a tutorial so that users can understand
what in the world does it do? For a starting point, I'd recommend
moving the EXAMPLES to the beginning of the man page, and moving the
any mention of git-diff-index, git-diff-files, and git-diff-tree to
the very end of the man page, and to put the most commonly used
options in the git-diff man page, so that most users don't have to
look at the low-level plumbing man pages to figure out how the
high-level git-diff works.
^ permalink raw reply
* How-to revert a locally modified file
From: Wink Saville @ 2006-12-01 5:23 UTC (permalink / raw)
To: git
Hello,
I searched the net and couldn't find the answer to how to revert a
file to its "pre-modified" state.
I did see in the 0.99.7 To Do:
* Perhaps a tool to revert a single file to pre-modification
state? git-cat-file blob `git-ls-files | grep foo` >foo or
git-cat-file blob `git-ls-tree HEAD foo` >foo? What should
the command be called? git-revert is taken so is
git-checkout.
Did such a command come to be?
Thanks,
^ permalink raw reply
* Re: How-to revert a locally modified file
From: Junio C Hamano @ 2006-12-01 5:51 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <456FBC63.5090609@saville.com>
Wink Saville <wink@saville.com> writes:
> Hello,
>
> I searched the net and couldn't find the answer to how to revert a
> file to its "pre-modified" state.
>
> I did see in the 0.99.7 To Do:
Where did you find 0.99.7 ToDo? I am curious...
> * Perhaps a tool to revert a single file to pre-modification
> state? git-cat-file blob `git-ls-files | grep foo` >foo or
> git-cat-file blob `git-ls-tree HEAD foo` >foo? What should
> the command be called? git-revert is taken so is
> git-checkout.
>
> Did such a command come to be?
commit 4aaa702794447d9b281dd22fe532fd61e02434e1
Author: Junio C Hamano <junkio@cox.net>
Date: Tue Oct 18 01:29:27 2005 -0700
git-checkout: revert specific paths to either index or a given tree-ish.
When extra paths arguments are given, git-checkout reverts only those
paths to either the version recorded in the index or the version
recorded in the given tree-ish.
This has been on the TODO list for quite a while.
Signed-off-by: Junio C Hamano <junkio@cox.net>
See the EXAMPLES section of git-checkout manual page.
^ permalink raw reply
* Re: Unprivileged User
From: Ed @ 2006-12-01 6:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jnareb, git
In-Reply-To: <7vwt5djmt5.fsf@assigned-by-dhcp.cox.net>
Thanks, I looked at the perl script and did it explicitly and it
works... I am on mac os x, but I do not know why that would affect the
behaviour of getpwuid...
On 11/30/06, Junio C Hamano <junkio@cox.net> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Ed wrote:
> >
> >> From gitweb it says that my git project's owner is: Unprivileged User
> > ...
> > Actually gitweb uses uid/user the repository (the $GIT_DIR), unless you
> > provide it with an index file.
>
> This is a shot in the dark, but by any chance is this repository
> owned by nobody, which is mapped to "Unprivileged User" by
> /etc/passwd? Googling for "Unprivileged User" and "getpwent"
> tells me that on OSX boxes nobody seems to map to that Gecos
> name.
>
> To explicitly set the names of list of projects and their
> owners, set up $projects_list text file. A hint for its format
> is found around line 1111 in gitweb/gitweb.perl script.
>
> Hopefully somebody has documentation for gitweb configuration
> so that people do not have to refer to the source to find things
> out, but I do not know of a URL offhand...
>
>
>
^ permalink raw reply
* Re: [RFC] git-add update with all-0 object
From: Junio C Hamano @ 2006-12-01 6:20 UTC (permalink / raw)
To: Theodore Tso; +Cc: Daniel Barkalow, Linus Torvalds, git
In-Reply-To: <20061201045727.GA22622@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> The question then is how can we fix the "git diff" man page, and how
> do we explain "git diff" in a tutorial so that users can understand
> what in the world does it do? For a starting point, I'd recommend
> moving the EXAMPLES to the beginning of the man page, and moving the
> any mention of git-diff-index, git-diff-files, and git-diff-tree to
> the very end of the man page, and to put the most commonly used
> options in the git-diff man page, so that most users don't have to
> look at the low-level plumbing man pages to figure out how the
> high-level git-diff works.
All good points. The only slight worry I have is that just
moving EXAMPLE up deviates from the traditional UNIX manpage
order of presenting information.
I think the plumbing manuals can (and probably should) stay as
the technical manual for Porcelain writers. "git diff", "git
add" and friends that are clearly Porcelain should talk about
what it does in the terms of end user operation in the
DESCRIPTION section and puts less stress on how things work
behind the scene in technical terms. For example, from
git-diff(1):
DESCRIPTION
-----------
Show changes between two trees, a tree and the working tree, a
tree and the index file, or the index file and the working tree.
The combination of what is compared with what is determined by
the number of trees given to the command.
That may be an accurate description of what the command does in
technical terms, but it does not tell why the user may want to
compare "a tree and the working tree". The users would want to
know which case applies to their current situation and we should
make it easier for them to find that information.
For example, although --cached is technically speaking one of
the --diff-options, it should be separated out from other
options when we talk about 'git-diff'. Also, although 'git-diff'
is designed to work on tree-ish, Porcelain users will use with
commit-ish (either a commit or an annotated signed tag that
points at a commit) 99.9% of the time, so we should mention
<tree-ish> at the end as a sidenote and talk about <commit>.
DESCRIPTION
-----------
This command shows changes between four combinations
of states.
* 'git-diff' [--options] [--] [<path>...]
is to see the changes you made relative to the index
(staging area for the next commit). In other words, the
differences are what you _could_ tell git to further add
to the index but you still haven't. You can stage
these changes by using gitlink:git-update-index[1].
* 'git-diff' [--options] --cached [<commit>] [--] [<path>...]
is to see the changes you staged for the next commit
relative to the named <tree-ish>. Typically you would
want comparison with the latest commit, so if you do
not give <commit>, it defaults to HEAD.
* 'git-diff' [--options] <commit> -- [<path>...]
is to see the changes you have in your working tree,
regardless of you staged them or not, relative to the
named <commit>.
* 'git-diff' [--options] <commit> <commit> -- [<path>...]
is to see the changes between two <commit>.
Just in case if you are doing something exotic, it
should be noted that all of the <commit> in the above
descriptoin can be any <tree-ish>.
^ permalink raw reply
* Re: How-to revert a locally modified file
From: Wink Saville @ 2006-12-01 6:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4psgduzg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Wink Saville <wink@saville.com> writes:
>
>
> Where did you find 0.99.7 ToDo? I am curious...
here: http://kerneltrap.org/node/5678
>
> git-checkout: revert specific paths to either index or a given tree-ish.
>
> When extra paths arguments are given, git-checkout reverts only those
> paths to either the version recorded in the index or the version
> recorded in the given tree-ish.
>
FYI the above seems more obvious then what's in the man page:
"It updates the named paths in the working tree from the
index file (i.e. it runs git-checkout-index -f -u)."
But for me saying something like;
"It reverts the paths in the working tree to the most recent version stored in git."
would even be better. It may not be as precise as the current sentence,
but more obvious to this neophyte. Finally, in the EXAMPLES you
might add another example of reverting a "modified the file" as
well as recovering a deleted file.
In any case thanks,
^ permalink raw reply
* Resolving conflicts
From: Wink Saville @ 2006-12-01 7:06 UTC (permalink / raw)
To: git
Sorry to be so ignorant, but I just updated to 2.6.19 using:
git-checkout master
git-pull
...
sound/usb/usbaudio.c | 3
usr/Makefile | 2
92 files changed, 888 insertions(+), 371 deletions(-)
create mode 100644 arch/mips/kernel/topology.c
create mode 100644 arch/um/os-Linux/execvp.c
create mode 100644 include/asm-arm/mach/udc_pxa2xx.h
All seemed to go I then moved back to my branch and pulled from master to my branch:
git-checkout ace
git-pull . master
But that failed:
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with 0215ffb08ce99e2bb59eca114a99499a4d06e704
Merging:
d7083db038fb98266e331a7f96198ec35a12367a A partial fix BUG 061124 (crashing when 1ms interrrupts).
0215ffb08ce99e2bb59eca114a99499a4d06e704 Linux 2.6.19
found 1 common ancestor(s):
1abbfb412b1610ec3a7ec0164108cee01191d9f5 [PATCH] x86_64: fix bad page state in process 'swapper'
Auto-merging kernel/fork.c
CONFLICT (content): Merge conflict in kernel/fork.c
Auto-merging kernel/spinlock.c
CONFLICT (content): Merge conflict in kernel/spinlock.c
Automatic merge failed; fix conflicts and then commit the result.
I then searched the net for how to resolve conflicts, seems you
should start by doing a git-diff, so I did and I get this:
diff --cc kernel/fork.c
index d74b4a5,8cdd3e7..0000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
diff --cc kernel/spinlock.c
index f4d1718,2c6c2bf..0000000
--- a/kernel/spinlock.c
+++ b/kernel/spinlock.c
And git-status shows:
# On branch refs/heads/ace
#
# Updated but not checked in:
# (will commit)
#
# modified: Documentation/rtc.txt
# modified: Makefile
# modified: arch/arm/configs/assabet_defconfig
# modified: arch/arm/configs/cerfcube_defconfig
......
# modified: sound/usb/usbaudio.c
# modified: usr/Makefile
#
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# unmerged: kernel/fork.c
# modified: kernel/fork.c
# unmerged: kernel/spinlock.c
# modified: kernel/spinlock.c
#
So what have I done wrong?
Did the pull complete and I just need to resolve this or
do I need to redo the git-pull?
Thanks,
Wink Saville
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Juergen Ruehle @ 2006-12-01 7:06 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910611301956l6f64b01ftee46971a18e3467b@mail.gmail.com>
Jon Smirl writes:
> Anyone have a nice script for suppressing diffs caused by CVS keyword
> expansion when someone checked the kernel sources into CVS?
I usually just say (with GNU diff)
diff -I $$ ...
which is crude, but should be enough to get rid of the hunks listed by
you.
You might also want -x CVS if you have the metadata files.
^ permalink raw reply
* Re: [RFC] git-add update with all-0 object
From: Linus Torvalds @ 2006-12-01 7:10 UTC (permalink / raw)
To: Theodore Tso; +Cc: Daniel Barkalow, git, Junio C Hamano
In-Reply-To: <20061201045727.GA22622@thunk.org>
On Thu, 30 Nov 2006, Theodore Tso wrote:
>
> By the way, after thinking about this for a while, part of the problem
> is that the name "index" really sucks.
Hey, it was originally called "cache".
I don't care _what_ it's called, I just want people knowing about it,
because hiding it will just cripple git (ie at the very least, when you
hit a merge conflict, you really do want to to understand it if you ever
want to go the the "next level").
If people are more comfortable just calling it the "staging area", and
talking about it in those terms, I'll be happy.
> Put another way, the reason why I think people are liking the whole
> "git add" and "git rm" suggestion is that it's a nice middle ground
> between the "hide the index" and the "shove the index in the user's
> face" approaches. It's not that we are hiding the fact that there is
> this thing with the horribly chosen name "index", but instead we talk
> about this concept of a staging area and we don't dwell on things like
> the fact that it is a binary file which stores an efficient
> representation of a virtual directory.... blah blah blah.
Yes.
And even "git diff" isn't really a problem once you understand the staging
area. If people feel worried, let them use "git diff HEAD". You won't need
to use git for _that_ long until you realize that since the staging area
is going to match the HEAD under normal circumstances (and when it
doesn't, you actually tend to prefer to get the diff against the staging
area _anyway_), you'll find people just starting to use "git diff" and not
worry about it.
^ permalink raw reply
* Re: Resolving conflicts
From: Alan Chandler @ 2006-12-01 7:30 UTC (permalink / raw)
To: git; +Cc: Wink Saville
In-Reply-To: <456FD461.4080002@saville.com>
On Friday 01 December 2006 07:06, Wink Saville wrote:
...
> git-pull . master
>
> But that failed:
I am not the worlds expert in this, but since most seem to be in bed I'll
attempt to answer you
...
> CONFLICT (content): Merge conflict in kernel/fork.c
> Auto-merging kernel/spinlock.c
> CONFLICT (content): Merge conflict in kernel/spinlock.c
These show that these two files had some conflicts in the contents from the
kernel and your local branch
...
> And git-status shows:
...
> # Changed but not updated:
> # (use git-update-index to mark for commit)
> #
> # unmerged: kernel/fork.c
> # modified: kernel/fork.c
> # unmerged: kernel/spinlock.c
> # modified: kernel/spinlock.c
> #
>
> So what have I done wrong?
Nothing - its asking you to manually resolve the conflict.
> Did the pull complete and I just need to resolve this or
> do I need to redo the git-pull?
Take a look in these two files - you should see conflict markers of the form
<<<<<<<<<<<<<<<<
some content
================
some other content
>>>>>>>>>>>>>>>>
which is the contents that failed from your side and the new version of the
kernel you pulled in.
Edit so the files have sensible content
then use
git update-index <filename>
to tell git that that particular conflict has been resolved.
When you have done that for both files
just do
git commit
--
Alan Chandler
^ permalink raw reply
* Re: Resolving conflicts
From: Linus Torvalds @ 2006-12-01 7:39 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <456FD461.4080002@saville.com>
On Thu, 30 Nov 2006, Wink Saville wrote:
>
> I then searched the net for how to resolve conflicts, seems you
> should start by doing a git-diff, so I did and I get this:
>
> diff --cc kernel/fork.c
> index d74b4a5,8cdd3e7..0000000
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> diff --cc kernel/spinlock.c
> index f4d1718,2c6c2bf..0000000
> --- a/kernel/spinlock.c
> +++ b/kernel/spinlock.c
Hmm. That doesn't look like a conflict. If it had a real conflict, I'd
have expected to see it mentioned in that diff..
This may be a stupid question, but if you haven't actually ever needed to
do any file-level merges before, this may be the first time you've
actually had the external 3-way "merge" program called, and that's one of
the few things that git still depends on _external_ programs for. And if
that program is broken or missing, you'd get bubkis.
(This is hopefully getting fixed, and we'll have one less external
dependency to worry about, but it's the only thing that springs to mind)
That's especially true since the merge-head your log shows wasn't even all
that long ago: there's just 80 commits since that common merge base, and
only two of them even change those two files, and only in rather simple
ways at that.
So my guess is that there wasn't actually a conflict at all, but the
"merge" program (usually in /usr/bin/merge) returned an error for some
reason. What does "which merge" and "rpm -qf /usr/bin/merge" say?
But you can also do "git diff --ours" (or "git diff --their") to get a
simple two-way diff of the end result of the merge to what you were
looking at.
^ permalink raw reply
* Re: Resolving conflicts
From: Wink Saville @ 2006-12-01 7:41 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200612010730.25700.alan@chandlerfamily.org.uk>
Alan Chandler wrote:
> On Friday 01 December 2006 07:06, Wink Saville wrote:
>
> Take a look in these two files - you should see conflict markers of the form
> <<<<<<<<<<<<<<<<
> some content
> ================
> some other content
>
That's what I thought but there isn't any "<<<<<" and git-diff also seems
to indicate no differences:
wink@winkc2d1:~/linux/linux-2.6$ git-diff kernel/fork.c
diff --cc kernel/fork.c
index d74b4a5,8cdd3e7..0000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
wink@winkc2d1:~/linux/linux-2.6$
wink@winkc2d1:~/linux/linux-2.6$ git-diff kernel/spinlock.c
diff --cc kernel/spinlock.c
index f4d1718,2c6c2bf..0000000
--- a/kernel/spinlock.c
+++ b/kernel/spinlock.c
wink@winkc2d1:~/linux/linux-2.6$
Thanks,
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Linus Torvalds @ 2006-12-01 7:44 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <17775.54363.376000.140259@lapjr.intranet.kiel.bmiag.de>
On Fri, 1 Dec 2006, Juergen Ruehle wrote:
> Jon Smirl writes:
> > Anyone have a nice script for suppressing diffs caused by CVS keyword
> > expansion when someone checked the kernel sources into CVS?
>
> I usually just say (with GNU diff)
>
> diff -I $$ ...
>
> which is crude, but should be enough to get rid of the hunks listed by
> you.
>
> You might also want -x CVS if you have the metadata files.
Also, if you are actually _using_ CVS to check it out, use
cvs co -ko
I think, to not check out with keyword expansion at all.
(Also usable with "cvs diff -ko", I think)
Linus
PS. Clueless user alert: I have happily not used CVS in years and years,
^ permalink raw reply
* Re: Resolving conflicts
From: Wink Saville @ 2006-12-01 7:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611302330000.3695@woody.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 30 Nov 2006, Wink Saville wrote:
>> I then searched the net for how to resolve conflicts, seems you
>> should start by doing a git-diff, so I did and I get this:
>>
>> diff --cc kernel/fork.c
>> index d74b4a5,8cdd3e7..0000000
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> diff --cc kernel/spinlock.c
>> index f4d1718,2c6c2bf..0000000
>> --- a/kernel/spinlock.c
>> +++ b/kernel/spinlock.c
>
> Hmm. That doesn't look like a conflict. If it had a real conflict, I'd
> have expected to see it mentioned in that diff..
>
> This may be a stupid question, but if you haven't actually ever needed to
> do any file-level merges before, this may be the first time you've
> actually had the external 3-way "merge" program called, and that's one of
> the few things that git still depends on _external_ programs for. And if
> that program is broken or missing, you'd get bubkis.
>
> (This is hopefully getting fixed, and we'll have one less external
> dependency to worry about, but it's the only thing that springs to mind)
>
> That's especially true since the merge-head your log shows wasn't even all
> that long ago: there's just 80 commits since that common merge base, and
> only two of them even change those two files, and only in rather simple
> ways at that.
>
> So my guess is that there wasn't actually a conflict at all, but the
> "merge" program (usually in /usr/bin/merge) returned an error for some
> reason. What does "which merge" and "rpm -qf /usr/bin/merge" say?
>
> But you can also do "git diff --ours" (or "git diff --their") to get a
> simple two-way diff of the end result of the merge to what you were
> looking at.
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Earlier had a problem with git wanting merge but didn't have it and
couldn't figure out which package it was in Ubuntu:( So I symlinked merge
to kdiff3 which worked at the time:
wink@winkc2d1:~/linux/linux-2.6$ ls -al /usr/bin/merge
lrwxrwxrwx 1 root root 6 2006-11-17 19:24 /usr/bin/merge -> kdiff3
But doesn't/didn't work this time.
I tried "git diff --ours"
wink@winkc2d1:~/linux/linux-2.6$ git diff --ours
* Unmerged path kernel/fork.c
diff --git a/kernel/fork.c b/kernel/fork.c
* Unmerged path kernel/spinlock.c
diff --git a/kernel/spinlock.c b/kernel/spinlock.c
wink@winkc2d1:~/linux/linux-2.6$
Wink
Not too helpful:(
^ permalink raw reply
* Re: Resolving conflicts
From: Linus Torvalds @ 2006-12-01 7:53 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611302330000.3695@woody.osdl.org>
On Thu, 30 Nov 2006, Linus Torvalds wrote:
>
> So my guess is that there wasn't actually a conflict at all, but the
> "merge" program (usually in /usr/bin/merge) returned an error for some
> reason. What does "which merge" and "rpm -qf /usr/bin/merge" say?
Side note: the historically more common failure was to not have a merge
program at all, but exactly because that was common, we check for that and
complain about it. So that's not it for you - you do have a 'merge'
program somewhere that git found.
But if it returns the wrong error code, or doesn't do anything at all (ie
you have "merge", but it's not the 3-way merge we expect, or it doesn't
take the "-L" argument we use, or it's simply buggy) then that might
explain the behaviour you report.
Or it might be something totally different. This is just a wild theory.
^ permalink raw reply
* Re: Resolving conflicts
From: Linus Torvalds @ 2006-12-01 7:57 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <456FDF24.1070001@saville.com>
On Thu, 30 Nov 2006, Wink Saville wrote:
>
> Earlier had a problem with git wanting merge but didn't have it and
> couldn't figure out which package it was in Ubuntu:( So I symlinked merge
> to kdiff3 which worked at the time:
Ahh. I'm pretty sure that is it.
No, kdiff3 probably doesn't have the same semantics, so better get the
"real" merge. It's almost certainly in the rcs package, so "emerge rcs"
should do it.
Or whatever system Ubuntu uses.
^ permalink raw reply
* Re: Resolving conflicts
From: Linus Torvalds @ 2006-12-01 8:00 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611302353580.3695@woody.osdl.org>
On Thu, 30 Nov 2006, Linus Torvalds wrote:
>
> No, kdiff3 probably doesn't have the same semantics, so better get the
> "real" merge. It's almost certainly in the rcs package, so "emerge rcs"
> should do it.
..and just to be safe, remove the symlink first, so that you don't end up
overwriting the "kdiff3" binary by mistake when you install the real
"merge". Not that I think emerge is quite that stupid a package manager,
but anyway..
^ permalink raw reply
* Re: Resolving conflicts
From: Alan Chandler @ 2006-12-01 8:10 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <456FDCB5.9040907@saville.com>
On Friday 01 December 2006 07:41, Wink Saville wrote:
> Alan Chandler wrote:
> > On Friday 01 December 2006 07:06, Wink Saville wrote:
> >
> > Take a look in these two files - you should see conflict markers of the
> > form <<<<<<<<<<<<<<<<
> > some content
> > ================
> > some other content
>
> That's what I thought but there isn't any "<<<<<" and git-diff also seems
> to indicate no differences:
This is at the limit of my understanding, but perhaps file permission problems
could have been the cause (was also thinking white space - but to my
recollection is that that DOES cause resolution markers)
I think you'll have to wait for experts from the list to comment.
--
Alan Chandler
^ permalink raw reply
* Re: [RFC] git-add update with all-0 object
From: Daniel Barkalow @ 2006-12-01 8:10 UTC (permalink / raw)
To: Theodore Tso; +Cc: Linus Torvalds, git, Junio C Hamano
In-Reply-To: <20061201045727.GA22622@thunk.org>
On Thu, 30 Nov 2006, Theodore Tso wrote:
> By the way, after thinking about this for a while, part of the problem
> is that the name "index" really sucks. Which is perhaps why Linus is
> now trying to stop us from actually using the term "index" in these
> discussions. :-) If we called it a "staging area", as our Great
> Leader has suggested, I think it would be a lot easier for novice
> users to understand. Consider what is in the git man page:
>
> The index is a simple binary file, which contains an efficient
> representation of a virtual directory content at some random
> time. It does so by a simple array that associates a set of
> names, dates, permissions and content (aka "blob") objects
> together. The cache is always kept ordered by name, and names
> are unique (with a few very specific rules) at any point in
> time, but the cache has no long-term meaning, and can be
> partially updated at any time.....
>
> In particular, the index file can have the representation of
> an intermediate tree that has not yet been instantiated. So
> the index can be thought of as a write-back cache, which can
> contain dirty information that has not yet been written back
> to the backing store.
>
> For a kernel programmer, this might not be understandable --- but for
> your typical application programmer, this is enough to cause him or
> her to conclude that git is simply not meant for use by mere mortals.
My position on this subject is that "index" is a good name, but that
description is a terrible description, and "index" is a word that needs a
good description in context. If we just said up front:
Git's "index" is a staging area that you use to prepare commits. It maps
filenames to content. It allows git to remember changes you want to put
into the next commit while you do more work. For normal commits, it is
not necessary to use the index, but it is very helpful for complicated
commits, because it lets you focus on the part you're still working on
while git remembers the part you're done with.
I think people would get it. (If it were called the "cache" still, it
would be hopeless, because "cache" implies false things; "index" doesn't
imply anything initially.)
Of course, we'd still have to disabuse people of the notion that the index
can store the information "there's nothing at this path yet, but I'm
interested in it", because that's a piece of information people often know
before a file is ready, and think git would be able to remember in a
staging area.
-Daniel
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Jeff King @ 2006-12-01 8:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wnnysrn.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 28, 2006 at 04:57:00PM -0800, Junio C Hamano wrote:
> > The top 15 for v1.4.3 to v1.4.4 are:
> >
> > 1604 6973dcaee76ef7b7bfcabd2f26e76205aae07858 Libify diff-files.
>
> Something is SERIOUSLY wrong.
>
> That commit is not even between v1.4.3 and v1.4.4.
Hmm, you're right. I haven't quite figured out what went wrong with the
script I posted. However, a somewhat simpler approach is to just use the
revision limiting in git-blame. The problem with this is that commits
whose parents aren't in the revision range end up getting blamed for a
lot of lines they're not responsible for.
As a quick hack, I just threw out any revisions whose parents weren't in
range. This is wrong, since those revisions probably _do_ have some
correctly blamed lines. It made me wonder about a possible feature for
git-blame: when we can't pass the blame up further, instead of taking
responsibility, output a "no responsibility line" (blaming on commit
0{40}, or some other format). I think this should be more informative
when there is a limit on the range of revisions.
The top of the "blamedness" list for v1.4.3..v1.4.4 is below. Important
things do seem to float to the top, but it would probably be much more
accurate if we were scoring groups of commits (generated by some other
analysis).
-Peff
-- >8 --
1050 cee7f245dcaef6dade28464f59420095a9949aac git-pickaxe: blame rewritten.
223 fe142b3a4577a6692a39e2386ed649664ad8bd20 Rework cvsexportcommit to handle binary files for all cases.
219 c31820c26b8f164433e67d28c403ca0df0316055 Make git-branch a builtin
216 636171cb80255682bdfc9bf5a98c9e66d4c0444a make index-pack able to complete thin packs.
182 b1f33d626501c3e080b324e182f1da76f49b5bf9 Swap the porcelain and plumbing commands in the git man page
173 744d0ac33ab579845808b8b01e526adc4678a226 gitweb: New improved patchset view
169 e30496dfcb98a305a57b835c248cbc3aa2376bfc gitweb: Support for 'forks'
142 5b329a5f5e3625cdc204e3d274c89646816f384c t6022: ignoring untracked files by merge-recursive when they do not matter
134 c0990ff36f0b9b8e806c8f649a0888d05bb22c37 Add man page for git-show-ref
128 780e6e735be189097dad4b223d8edeb18cce1928 make pack data reuse compatible with both delta types
121 2d477051ef260aad352d63fc7d9c07e4ebb4359b add the capability for index-pack to read from a stream
116 576162a45f35e157427300066b0ff566ff698a0f remove .keep pack lock files when done with refs update
110 e827633a5d7d627eb1170b2d0c71e944d0d56faf Built-in cherry
^ permalink raw reply
* Re: Resolving conflicts
From: Alan Chandler @ 2006-12-01 8:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611302359400.3695@woody.osdl.org>
On Friday 01 December 2006 08:00, Linus Torvalds wrote:
> On Thu, 30 Nov 2006, Linus Torvalds wrote:
> > No, kdiff3 probably doesn't have the same semantics, so better get the
> > "real" merge. It's almost certainly in the rcs package, so "emerge rcs"
> > should do it.
>
> ..and just to be safe, remove the symlink first, so that you don't end up
> overwriting the "kdiff3" binary by mistake when you install the real
> "merge". Not that I think emerge is quite that stupid a package manager,
> but anyway..
Ubuntu is a Debian based. I think it uses Synaptic as its package manager gui
with the standard Debian apt-xxx tools underneath.
--
Alan Chandler
^ 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