* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Theodore Tso @ 2006-11-30 16:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Johannes Schindelin, Junio C Hamano, Carl Worth,
Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.64.0611300749560.3513@woody.osdl.org>
On Thu, Nov 30, 2006 at 07:58:09AM -0800, Linus Torvalds wrote:
> So I wanted to make it clear that I never have that situation, because I
> never leave the index "dirty". I agree that there is nothing odd about it,
> but I think that people who don't actively use the index (or don't use git
> at all, and just worry about it) see it as a kind of separate entity with
> a life all its own.
Well, sure, because the documentation *talks* about it as a separate
entity all its own. Just look at the man page for git-diff as a great
example of this, or the ascii art diagram of the index. It is all
technically _correct_, but it is scary as all heck.
> I can see that if you think the index is likely to be out of kilter with
> HEAD, you'd always worry about "ok, so maybe the diff I get from 'git
> diff' isn't the _true_ diff, so now I have to do _both_ 'git diff' and
> 'git diff HEAD' to make sure I know what's up".
>
> I just wanted to clarify that that is never the case for me, and I doubt
> anybody else really does it either.
But then why is the default for "git commit" to commit the index, if
the index is almost == HEAD? And why is git-update-index given such
prominence in the documentation?
> In other words, the fact that the index _normally_ matches the HEAD may be
> obvious, but it's also important - it's important to allay fears from
> non-index users about it being somehow scary and confusing. It's not.
If everyone agrees with this, I think it would be easier to make
changes to the documentation and maybe some UI tweaks about what the
default might be.
One suggestion is that perhaps a mode where warns users when index !=
HEAD for certain critical commands might not be a bad thing. That
might give users that are just graduating beyond novice git usage, and
just starting to become aware of the index, reassurance because if
they *don't* see the warning message, they can rest assured that they
don't have to do both "git diff" and "git diff HEAD", for example.
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-30 16:45 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Joseph Wakeling, git, bazaar-ng
In-Reply-To: <456ED047.3030102@ableton.com>
On Thu, 30 Nov 2006, Nicholas Allen wrote:
>
> Does this mean if I have, for example, a large C++ file with a bunch of
> methods in it and I move one of the methods from the bottom of the file to the
> top and in another branch someone makes a change to that method that when I
> merge their changes git will merge their changes into the method at the top of
> the file where I have moved it?
Right now (and in the near future), nope. "git blame" will track the
changes (so the pure movement wasn't just an addition of new code, but
you'll see it track it all the way down to the original), but "git merge"
is still file-based.
In other words, "git merge" does uses a data similarity analysis that
could be used for smaller chunks than a whole file, but at least for now
it does it on a file granularity only (and then passes it off to the
standard RCS three-way merge on a file-by-file basis).
That said, if the movement happens _within_ a file, then just about any
SCM could do what you ask for, by just using something smarter than the
standard 3-way merge. So that part isn't even about tracking data across
files - it's just about a per-file merge strategy.
The "track data, not files" thing becomes more interesting when you factor
out a file into two or more files, and can continue to merge across such a
code re-filing event. Git can do it for "annotate", but doesn't do it for
anything else.
> If so that would be really quite impressive!
Indeed, and it's one of the potential future goals that was discussed very
early in the git design phase. The point of _not_ doing file ID tracking
is exactly that you can actually do better than that by just tracking the
data.
So some day, we may do it. And not just within one file, but even between
files. Because file renames really is just a very specific special case of
data movement, and I don't think it's even the most common case.
That said, there are several reasons why you might not actually _ever_
want it in practice, and why I say "potential future goal" and "we may do
it". I think this is going to be both a matter of not just writing the
code (which we haven't done), but also deciding if it's really worth it.
Because merges are things where you may not want too much smarts:
- Quite often, a failed merge that needs manual fixup may even be
_preferable_ to a successful merge that did the merge "technically
correctly", but in an unexpected way.
- There's a _big_ difference between "merging code" and "examining code".
It makes much more sense to try to track where code came from and what
the "deep history" was when you examine code, because the reason you're
doing so is generally exactly because you're looking for what went
wrong, and who to blame.
When going "merging", the history of the code is arguably a lot less
important. What is the most important part is that the two branches you
merge have been (hopefully) verified in their _current_ state. The
history may be full of bugs, and they may have been fixed differently,
and even trying to be really clever may not actually be a good idea at
all.
Code may have moved or may have been copied, but what is much more
important than the original code and where it came from is the state it
was in _after_ the move, because that's the tested working state, and
in many ways the history of how it came to be really shouldn't matter
as much at all.
In other words, "annotate" and "merge" have almost entirely opposite
interests. An annotation is supposed to find the history in order to maybe
help find bugs, while a merge is supposed to use the _current_ state, and
very arguably, if the two current states don't match _so_ obviously that
there is no question about what you should do, then the merge should make
that very very very clear to the user.
So my personal opinion has always been that a merge should be extremely
simpleminded. I think all teh VCS people who concentrate on smart merging
absolutely have their heads up their arses, and do exactly the wrong
thing. A merge should not do anything "clever" at all. It should be just
_barely_ smart enough to do the obvious thing, and even then we all know
that it will still occasionally do the wrong thing.
So I actually think that a bog-standard and totally stupid three-way merge
is simply not far from the right thing to do. And the git "recursive"
thing basically repeats that stupid merge (a) in time (ie the criss-cross
merge thing causes a recursive three-way merge to take place) and (b) in
the metadata space (ie you can see the rename following basically as just
a "3-way merge in filenames").
And yes, this is probably some mental deficiency and hang-up, but I think
that's sufficient, and that where the real "clever" stuff should be is to
then help people resolve conflicts (and maybe also help you find
mis-merges even with the totally stupid and simple merge). Because
conflicts _will_ happen, regardless of your merge strategy, and you do
need people to look at them, but you can make it _easier_ for people to
say "ok, that's obviously the right merge".
So me personally, I'd rather have the "real merge" be what git already
does, and then have something like a graphical "resolution helper"
application that tries to resolve the remaining things with user help. And
that "resolution helper" is where I'd put all the magic code movement
logic, not in the merge itself.
So you could look at a failed hunk, and press a "show me a best guess"
button, and at that point the thing would say "that code might fit here,
does that look sane to you? <Ok>, <Next guess>, <Cancel>".
THAT is what a good VCS should do, in my opinion. Not do "smart merges".
Btw, git doesn't do the above kind of smart graphical thing, but git
_does_ do something very much in that direction. Unlike a lot of things,
git doesn't just leave the "conflict marker" turds in the working tree.
No, the index will contain the three-way merge base and both of the actual
files you were trying to merge, and a "git diff" will actually show you a
three-way diff of the working tree (and you can say "git diff --ours" to
see the diff just against our old head, and "--theirs" to see a regular
two-way diff against the _other_ side that you tried to merge).
So git already very much embodies this concept of "don't be overly smart
when merging, but try to help the user out when resolving the merge". It
may not be pretty GUI etc, and it mostly helps with regular bog-standard
data conflicts, but boy is it pleasant to use for those once you get used
to it.
So we get NONE of those horrible "you just get conflict turds, you figure
it out" things. It gives you the turds (because people, including me, are
used to them, and you want _something_ in the working tree that shows both
versions at the same time, of course), but then you can edit them to your
hearts content, and even _after_ you've edited them, you can do the above
three-way (or two-way against either branch) diffs, and it will show what
you edited and its relationship to the two branches you merged.
THAT is what merging is all about. Not smart merges. Stupid merges with
good tools to help you do the right thing when the right thing isn't _so_
obvious that you can just leave it to the machine.
^ permalink raw reply
* [PATCH] Use git-rev-parse --git-dir to determine GIT_DIR
From: Peter Baumann @ 2006-11-30 16:45 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
Signed-off-by: Peter Baumann <siprbaum@stud.informatik.uni-erlangen.de>
---
gitk | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/gitk b/gitk
index ab383b3..60f8212 100755
--- a/gitk
+++ b/gitk
@@ -8,12 +8,7 @@ exec wish "$0" -- "$@"
# either version 2, or (at your option) any later version.
proc gitdir {} {
- global env
- if {[info exists env(GIT_DIR)]} {
- return $env(GIT_DIR)
- } else {
- return ".git"
- }
+ return [exec git rev-parse --git-dir]
}
proc start_rev_list {view} {
--
1.4.3.3
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-11-30 17:06 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611292000.23778.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6067 bytes --]
hoi :)
On Wed, Nov 29, 2006 at 08:00:22PM +0000, Andy Parkins wrote:
> 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.
What about:
You decide to try something out quickly and create a new branch in the
submodule. After you have verified that it works, you merge it to the
submodules master branch and commit that to the supermodule.
Not that complicated, isn't it?
In fact, my current implementation does not even allow to change the
branch name of the submodule which is tracked by the supermodule ;-).
> > 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?
Please excuse that I am not an native english speaker and I may have
caused some confusion here.
> That should be done by update-index in the supermodule.
That is exactly what I wanted to say. In the supermoduel you call
update-index (with the submodule path as argument) to update the index
of the supermodule. Just like normal files. Nothing new.
> 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.
This is handled in the next paragraph.
The argument really is: HEAD always points to the checked out branch,
so it really has a relationship to the working directory.
> > 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.
Yes, it's not a real counter-argument, but it relativates the previous
pro-argument.
> > - 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.
yes, but luckily GIT branches are very flexible.
> 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.
I don't think it is that bad.
> > Pro refs/heads/master:
> > - the supermodule really tracks one defined branch of development.
>
> Why is this a pro?
You always know which branch in the submodule is the "upstream" branch
which is managed by the supermodule.
You can easily have several topic-branches and merge updates from the
master branch.
otherwise you always have to remember which branch holds your current
contents from the supermodule.
When viewed from the supermodule, you are storing one branch per
submodule in your tree.
> > - 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.
Suppose you are working on a complicated feature in one submodule.
You create your own branch for that feature and work on it.
Now you want to update your project, so you pull a new supermodule
version. Now this pull also included one (for you unimportant) change
in the submodule.
I think it is more clear to update the master branch with the new
version coming from the supermodule, while leaving your work intact
(you haven't commited it to the supermodule yet, so the supermodule
should not care about your changes, it's just some dirty tree).
Then you can freely merge between your branch and master as you like and
are not forced to merge at once. And perhaps you even do not want to
merge at all, because you are on an experimental branch which really is
mutually exclusive with the current supermodule contents.
> > 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.
Of course you know: git-status will tell it.
This is no different to today, where you can commit while still leaving
a part of the tree dirty.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Andy Whitcroft @ 2006-11-30 17:13 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <ekmkoe$a52$1@sea.gmane.org>
Salikh Zakirov wrote:
> Junio C Hamano wrote:
>> I've been playing with a "private edition" git to see how it
>> feels like to use "git commit" that defaults to the "-a"
>> behaviour, using myself as a guinea pig, for the rest of the
>> evening.
>
> Thanks a lot for the patches, Junio!
>
> I am using them for two days, and my experience is great!
> Many times it saved me annoyances of forgetting to put '-a' to 'git commit'.
>
> It should be noted, that I mostly used 'git-commit files...'
> or 'git-commit -a' forms before.
>
> Someone said, that default '-a' does not go well with 'git-commit --amend',
> and I second that. It was somewhat suprising to see that 'git commit --amend'
> is going to include all of the dirty state into the commit,
> and since there is no easy way to abort a --amend commit (because the comment
> buffer wasn't empty, and :q! does not work as it would on the regular commit),
> I had to untwine the changes manually.
If you have no commit message the commit will be aborted. So just write
back a completly empty commit message. "dG:wq" in vi land.
apw@larry:~/git/linux-2.6$ git commit --amend
* no commit message? aborting commit.
apw@larry:~/git/linux-2.6$
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Linus Torvalds @ 2006-11-30 17:13 UTC (permalink / raw)
To: Theodore Tso
Cc: Andreas Ericsson, Johannes Schindelin, Junio C Hamano, Carl Worth,
Nicolas Pitre, git
In-Reply-To: <20061130164046.GB17715@thunk.org>
On Thu, 30 Nov 2006, Theodore Tso wrote:
>
> But then why is the default for "git commit" to commit the index, if
> the index is almost == HEAD? And why is git-update-index given such
> prominence in the documentation?
The default is: commit everything that you ask for to be committed.
If you haven't marked anything to be committed (which you can do with "git
add" too, or with simply being in the middle of a merge, or by having done
something like "git pull -n" or similar that does everything _but_
commit), then git commit will say "nothing to do".
It has NOTHING to do with the index per se.
I still don't understand why people are so hung up about the index.
So ignore the index entirely, and follow along with me:
"git commit" with no parameters simply DOES NOT DO ANYTHING YOU
HAVEN'T ALREADY ASKED YOU TO DO.
It's that simple. It's that logical. Ignore the index. Ignore everything
else. Just read that simple, straightforward, and logical sentence on its
own. It all makes sense.
Then, the trivial follow-up is:
If you want to commit _all_ dirty files, use "git commit -a".
Otherwise, name the files or subdirectories you want to commit
explicitly.
Again: THIS JUST MAKES SENSE.
Asking for "-a" to be the default behaviour is BAD.
For example, in "git commit --amend", it's _important_ that "-a" not be
the default, because you may well want to just amend the commit _message_.
No files updated AT ALL. You may have other state that is still dirty
(because you didn't ask it to be committed last time), and they should NOT
be committed, because the simple rule is:
"git commit" with no parameters simply DOES NOT DO ANYTHING YOU
HAVEN'T ALREADY ASKED YOU TO DO.
Repeat the above sentence again. IT JUST MAKES SENSE.
So maybe the documentation shouldn't mention the "index" at all, because
it apparently scares and confuses people. But the fact is, the
documentation started out as _technical_ documentation, that explains the
_technical_ side of git. We don't have lots of "end-user" docs.
But the lack of such end-user documentation should not cause idiotic
threads like this, where people blame "the index".
Yeah, so the docs are too scary. But none of this has anything to do with
"the index". It's all logical on its own, and the default behaviour to not
commit anything you haven't asked to be committed is the right one.
Make "git commit" just say "You didn't say what you wanted to commit.
Maybe you meant 'git commit -a'" if there's nothing to commit. How hard
can that be? But don't change semantics now, and please DO NOT change them
to something _worse_ than what we have now (and automatically adding the
"-a" only in _certain_ circumstances is definitely much worse imnsho)
^ permalink raw reply
* Re: [PATCH/RFC] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Alex Riesen @ 2006-11-30 17:14 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611301259.32387.andyparkins@gmail.com>
On 11/30/06, Andy Parkins <andyparkins@gmail.com> wrote:
> "Maybe we could do git-commit -a _only_ if the index matches HEAD, and
> otherwise keep current behavior? So people who don't care about the
> index won't get tripped up, and when you do have a dirty index, you get
> told about it?"
The is dangerous on filesystems which lie to the programs about file metadata.
The "virtual filesystem" of cygwin is one of this kind: exec-bit of
the files depend
on its contents. Just calling git-commit -a will commit executability
at this particular
moment. For whatever reason, disabling handling of the exec-mode in gits config
does not work.
If you about to change the behaviour, provide at least a config option
to go back
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-11-30 17:19 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611301530.51171.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
hoi :)
On Thu, Nov 30, 2006 at 03:30:49PM +0000, Andy Parkins wrote:
> Well, I know what the commit is /that/ was all that was stored. So I
> (actually supermodule-git does):
>
> cd $DIRECTORY_ASSOCIATED_WITH_SUBMODULE
> git checkout -f $COMMIT_FROM_SUPERMODULE
>
> Obviously, this is grossly simplified. It also requires that HEAD be allowed
> to be an arbitrary commit rather than a branch, but that's already been
> generally agreed upon as a good thing.
It's not that easy.
You also have to make sure that all your submodule commits that _ever_
have been part of your submodule have be stay in your repository
forever.
Consider that your submodule switches to an other branch and some
old commits are not referenced by the current version any more.
These old commits still have to survive a git-prune, if they have been
part of some old supermodule version.
So you really have to connect both object databases and it's not enough
to just store the commit sha1 without actually parsing it by the GIT
core.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nicolas Pitre @ 2006-11-30 17:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Andreas Ericsson, Johannes Schindelin,
Junio C Hamano, Carl Worth, git
In-Reply-To: <Pine.LNX.4.64.0611300903080.3513@woody.osdl.org>
On Thu, 30 Nov 2006, Linus Torvalds wrote:
> The default is: commit everything that you ask for to be committed.
>
> If you haven't marked anything to be committed (which you can do with "git
> add" too, or with simply being in the middle of a merge, or by having done
> something like "git pull -n" or similar that does everything _but_
> commit), then git commit will say "nothing to do".
Might it be a good idea to have "git-add" do the same as
"git-update-index" on already tracked files? That could be easily
taught as "you must explicitly _add_ files to your next commit" and
whether the file is already tracked or not wouldn't matter. This would
help newbies actually getting used the index without mentioning the
dreaded word "index" at all.
Right now git-add on an already tracked file does nothing, not even a
message to say it did nothing.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Carl Worth @ 2006-11-30 18:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Andreas Ericsson, Johannes Schindelin,
Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.64.0611300903080.3513@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 4791 bytes --]
On Thu, 30 Nov 2006 09:13:52 -0800 (PST), Linus Torvalds wrote:
> On Thu, 30 Nov 2006, Theodore Tso wrote:
> >
> > But then why is the default for "git commit" to commit the index, if
> > the index is almost == HEAD? And why is git-update-index given such
> > prominence in the documentation?
>
> The default is: commit everything that you ask for to be committed.
...
> It has NOTHING to do with the index per se.
OK. I'll try to not mention the "index" any more in any postings
here.
And can we agree that any time git spits out a message directing the
user to use update-index that that's a (minor) user-interface wart?
> "git commit" with no parameters simply DOES NOT DO ANYTHING YOU
> HAVEN'T ALREADY ASKED YOU TO DO.
I think the response that would come from the people that are confused
is:
"But I told git I wanted to track this file when I said 'git
add' long ago. Why is it making me tell it again."
As you mentioned, all systems have _some_ mechanism for keeping track
of the files to be committed, (and git's is only unique in having a
name and providing more functionality for direct manipulation and lots
of extra information in the case of a merge conflict).
But I think most every system out there _except_ git default to a
state of committing every file it "knows" about as it exists in the
working tree, and then allowing the user to restrict that behavior to
some subset of the files.
Git allows the same subsetting, and has behavior that is very similar
to these other systems when the user provides a list of files.
Git also provides a unique mode in that users can "stage" file state
to be committed later in spite of subsequent different changes being
made to the same files in the working tree that won't be
committed. Some git users love this functionality. But mentioning it
to new users does scare them off to some extent, ("Why would I _want_
to do that?", "What if that happens accidentally?").
And I think one thing that happens is that the current defaults
naturally lead users to hear about this "scary" functionality, even if
the presenter, (whether a human or printed documentation), isn't
trying to go that direction:
Presenter: So use "git commit -a" here.
New user: Why -a?
Presenter: To tell git that you want to commit all files rather
than having to list them all on the command line.
New user: Why not just "git commit" for that then?
Presenter: Because that's something else.
New user: What's that?
Presenter: It lets you stage things---stuff you think is ready to
commit, but when you want to delay that commit until
after making other changes to the files that you don't
want to commit.
New user: What? Really? That's bizarre.
Presenter: It can be useful in some situations. But for now,
just use "commit -a" and it will do what you want.
And at this point the user either trusts me, accepts it, gives git a
try and falls in love, or the user gives up and uses something else.
I think the above accurately captures the essence of actual
conversations I've had with new new users. And I'd be glad to take
suggestions on how to improve what I say here. But it's that feeling
of "git is bizarre" that I'd like to reduce, and I'd like to improve
the success rate of the conversation, (though I think I've done pretty
well for people that trust me).
And note that the same kind of conversation happens when using git
directly with tutorials and man pages, but without a human
presenter. Only, there the conversation is much worse. First, it's
harder to pull off "just trust me and give it a try" in technical
documentation. Second, the documentation does not do a good job of
letting the user know when they're getting more technical information
than they need.
For example, there's "git status", (used by "git commit"), that
directs the user to "git update-index". Then there's the documentation
of git-commit that says "Updates the index file...and makes a commit
object."
And so far my best response to those problems is to short-cut them by
improving the defaults of git-commit, (the documentation should be
improved too, and I did submit a patch to get "update-index" out of
git-status output for example).
Anyway, I'm repeating myself on some of these details, but only
because some people still haven't seemed to grasp the real, new-user
confusion that arises here.
That's really what I'm trying to reduce with all the talk about
"commit all known files by default".
> "git commit" with no parameters simply DOES NOT DO ANYTHING YOU
> HAVEN'T ALREADY ASKED YOU TO DO.
>
> Repeat the above sentence again. IT JUST MAKES SENSE.
Yes. And it makes sense for the user to be able to say "unless I tell
you differently, I want to always commit the working-tree state of
<files> with every commit".
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Jon Loeliger @ 2006-11-30 18:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Git List
In-Reply-To: <7vvel2yi2u.fsf@assigned-by-dhcp.cox.net>
On Sat, 2006-11-25 at 21:58, Junio C Hamano wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Needing to put + in front of a refspec (or needing to fetch it with
> > --force) is the user agreeing that something _evil_ is going on with
> > the upstream and that they acknowledge this may cause problems for
> > them locally.
> >
> > I would prefer to see the upstream be able to publish a short
> > description of each branch, where the repository owner can describe
> > the policy of that branch, as well as have a machine readable
> > setting on each branch indicating if that branch will be rewound
> > from time to time, or never rewound.
> >
> > git-clone should skip rewinding branches by default, unless the user
> > adds an option (e.g. --include-rewinding-branches). This way new
> > users to git.git don't get the `pu` branch unless they really mean
> > to get it, at which point they have hopefully also read the upstream's
> > description of the `pu` branch and its rewinding policy, and can
> > at least start to grasp what is going to happen if they start to
> > work with the branch.
>
> I like this approach very much.
I see how it is! :-) When Shawn says it, it is to be liked.
But when I allude to it a _year_ ago, I'm ignored.
From: Jon Loeliger <jdl@freescale.com>
To: git@vger.kernel.org
Subject: Re: Trying to Update All Heads of a Repository
Date: Fri, 4 Nov 2005 07:49:40 -0700
Message-ID: <E1EY2su-0006LW-IN@jdl.com>
So, from the git-pull man page:
For "git push", the local ref that matches <src> is
used to fast forward the remote ref that matches
<dst>. If the optional plus + is used, the remote
ref is updated even if it does not result in a fast
forward update.
Ah-ha! Wait. But here's the conceptual missing piece:
When might I _know_ I have the situation where a
fast-forward update might not happen? And as a remote
puller, that would be "never" -- unless I know something
about the nature of the remote end. That is, like you
said, "pu" is subject to wild fluctuation and non-linear
behavior. But any random puller can't know that a
priori. So far, that is out-of-band information about a
branch that needs to be "available".
Yep, out-of-band information that needs to be available indeed...
Ah well. :-)
jdl
^ permalink raw reply
* Re: git blame [was: git and bzr]
From: Joseph Wakeling @ 2006-11-30 18:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611290830010.3395@woody.osdl.org>
Linus Torvalds wrote:
> So it's fixed now, and probably would never trigger except for the stupid
> special case that was "let's just show an example of this" ;)
I'm very happy my stupidity could help. ;-)
On a related note ...
Nicholas Allen wrote:
> Thanks for the informative response. It helped but I'm still slightly
> confused by git - I think I need to play around with it a bit more to
> understand and get more familiar with the concepts...
>
> Purely from an initial usage point of view though, for me at least, the
> bzr output needed no explanation which I think is indicative of a good
> user interface whereas the git was not so clear or obvious - there must
> be room for improvement in git's user friendliness here surely. But that
> might just be because I am clueless when it comes to the way git works
> and the concepts it uses ;-)
I do think that bzr has quite an intuitive set of commands, and it is
easy to learn, though at this point I don't feel git is really *that*
much more difficult in itself. Although the terminal output for some
problems could be improved, most of my difficulties are stemming from
overlap of command names when the commands themselves do different
things, and the fact that git's documentation is somewhat more technical
than bzr's.
What would be nice would be to have in the documentation a whole bunch
of stupid examples for the main commands, something where someone can
create a repo from scratch, create and modify some simple files
according to instructions, and see the particular command in action.
The tutorials do this, of course, but only for a few cases, when to be
honest it's the more complex commands that most need such explanation.
For beginners, especially less technically skilled ones, it would be
good to have a lot more of, "Do this, here's what git will respond, this
is what it means, here's how to fix it...."
As a relatively non-technical user, perhaps I should keep track of my
difficulties (and others') and try to write something up.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Linus Torvalds @ 2006-11-30 18:33 UTC (permalink / raw)
To: Carl Worth
Cc: Theodore Tso, Andreas Ericsson, Johannes Schindelin,
Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <87k61cu7qe.wl%cworth@cworth.org>
On Thu, 30 Nov 2006, Carl Worth wrote:
> >
> > Repeat the above sentence again. IT JUST MAKES SENSE.
>
> Yes. And it makes sense for the user to be able to say "unless I tell
> you differently, I want to always commit the working-tree state of
> <files> with every commit".
If so, you should make it a special case.
I refuse to believe in the "people who know what the hell they are doing
should work more at it" philosophy.
The "git commit -a" behaviour as it is now is better than the
alternatives, exactly because it's more flexible. It _allows_ you to not
commit anything at all (and as already mentioned, there are cases where
that is exactly what you want).
If you want to have a "-a by default", then that you require _you_ to do
more work, and no, it's NOT an excuse to say "I'm a clueless newbie, and I
don't know how to set a config option, so I think it's the smart and
beautiful people who should suffer for my shortcomings".
You can even do it by doing an alias like
[alias]
ci = commit -a
and then you can revel in your CVS-induced mudpit all you want. Just
don't try to convince people who have gotten over that braindamage to live
in the same muck with you.
Problem solved. For all I care, we can make that alias a default one, so
people who just can't get their mind out of the gutter that is CVS can
continue with their evil ways.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Carl Worth @ 2006-11-30 18:38 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Linus Torvalds, Theodore Tso, Andreas Ericsson,
Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611301229290.9647@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
On Thu, 30 Nov 2006 12:37:49 -0500 (EST), Nicolas Pitre wrote:
> Might it be a good idea to have "git-add" do the same as
> "git-update-index" on already tracked files? That could be easily
> taught as "you must explicitly _add_ files to your next commit"
I think this is worth doing, but it doesn't solve the problem.
It would be nice if this worked, because then it would be natural to
teach users to "git add" their changes, and then when the obvious
complaint about that being annoying to type all the time, then respond
by teaching "git commit -a" as a shortcut. That would be very natural.
But this doesn't quite work. Here's a major "index is confusing"
scenario that I first hit on my first exposure to git, (it was so long
ago that I completely forgot about it when when Linus asked what the
big deal is about the index).
It's all about the fine details of what "git add" does that can be
_extremely_ surprising to new users. Here's a simple scenario:
$ git init-db
defaulting to local storage area
$ echo "hello wurld" > hello
$ git add hello
# Oops! Look at that typo.
$ echo "hello world" > hello
$ git commit -m "add hello"
Committing initial tree 0267c1bf2956b3df47851e0163f2ea86c002379d
$ git diff
diff --git a/hello b/hello
index b1df5e6..3b18e51 100644
--- a/hello
+++ b/hello
@@ -1 +1 @@
-hello wurld
+hello world
And here the new user reaction is "What?! I fixed that before I
made the commit! What kind of broken system is this."
The above example is not at all surprising to someone who understands
the index. And it's that "why should that behavior be confusing"
disconnect that I'm trying to bridge here. Can you see why the above
confuses new users?
In most other systems I've used, 'add' means "I want the system to
'know' about this file" while 'commit' means "Please commit the
current state of all files you 'know' about (or the ones I mention
here on the command line)".
The current semantics do nothing to avoid this "interaction bug" and
there is no way to explain it to the user without going through an
"explanation of the index" and the user is left to decide that the
index is just there to help make broken commits.
So, I'd love for "git add" to be a shorter way to type "update-index",
(I have been campaigning for eliminating hyphens after all), but
without different semantics _somewhere_ the default behavior still is
potentially very confusing. The "ignore the index" stance Linus has
been proposing recently just doesn't work here.
And all of this contributes to make git harder to learn than it should
be.
-Carl
PS. It was actually "hard" for me to create that example above. The
first time I ran through the commands I ended up with an empty diff at
the end. "Huh? I _know_ that git does surprising things here." That
was because I was using Junio's "commit -a" patch which did right
thing rather than demonstrating the old wrong behavior I was trying to
demonstrate.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git blame [was: git and bzr]
From: Linus Torvalds @ 2006-11-30 18:44 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: git
In-Reply-To: <456F21D6.1060200@webdrake.net>
On Thu, 30 Nov 2006, Joseph Wakeling wrote:
>
> What would be nice would be to have in the documentation a whole bunch
> of stupid examples for the main commands, something where someone can
> create a repo from scratch, create and modify some simple files
> according to instructions, and see the particular command in action.
100% agreed. A lot of the man-pages etc have been written to be about the
technology, not about the _use_ of it.
I encouraged people at some point to add an "Examples" section to some of
the functions to show what it all _means_, so for "man git-log", I think
some of the most useful stuff is that examples section that shows the
combination of revision naming and path-name limiting, for example. I
personally think that that is a much better way of teaching people what
the commands actually do than by mentioning the arguments one by one.
But that only exists for a couple of man-pages, and mostly for the simple
ones at that. And a lot of the real examples would need "real data" to
work on, so it can't easily be done as a trivial example in a man-page, it
really needs a tutorial to "build up" to the situation where you can then
explain with an example what to do.
> The tutorials do this, of course, but only for a few cases, when to be
> honest it's the more complex commands that most need such explanation.
Yeah. The git "tutorial.txt" should be extended, and preferably be a while
nice set of "follow along with the bouncing ball" kind of web-page
sequence.
So I absolutely agree. It's just that at least me personally, I just can't
write documentation. I wrote some of the original tutorial, I've written
some of the original tech docs, but I just can't get into the whole
"document it" mindset, especially not from a user perspective. It doesn't
float my boat, and judging by a lot of the discussions, I obviously also
don't even see why something could _possibly_ cause confusion.
To make things worse, a lot of the docs (and by that I also mean some of
the error messages and helpful hints) tend to be old.
The whole fact that "git commit" mentions "git update-index" is exactly
that kind of thing: it's largely a legacy message. You'd almost never
actually _use_ git-update-index itself these days, and it's much more
convenient to just list the files you want to commit to "git commit"
directly (or just use the -a flag, if that is what you want to do).
But that message exists, because it was written in an earlier age.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Jakub Narebski @ 2006-11-30 18:47 UTC (permalink / raw)
To: git
In-Reply-To: <87irgwu6e6.wl%cworth@cworth.org>
Carl Worth wrote:
> In most other systems I've used, 'add' means "I want the system to
> 'know' about this file" while 'commit' means "Please commit the
> current state of all files you 'know' about (or the ones I mention
> here on the command line)".
while in git "git add" means "I want to add this file" (in the state
it is now) and not "I want the system to 'know' about this file".
And "commit" mean "Please commit the current 'known' state of all
files (or/and the current state of files I mention here on the
comand line)".
Yes, this is different than what other SCM do...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Carl Worth @ 2006-11-30 18:51 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Linus Torvalds, Theodore Tso, Andreas Ericsson,
Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <87irgwu6e6.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]
On Thu, 30 Nov 2006 10:38:25 -0800, Carl Worth wrote:
> And it's that "why should that behavior be confusing"
> disconnect that I'm trying to bridge here. Can you see why the above
> confuses new users?
By the way, I think I've said all I can in this thread.
If the "create file; git add; edit file; git commit" confusion isn't
blisteringly obvious to the git maintainers then I think I have to
give up here.
And this isn't just CVS-induced brain damage. It's the user being
required to mentally juggle 3 states for the file, (the last
"committed" state, the current "working tree" state, and this
"something else" state). The sequence above, (which is very natural),
exposes this "something else" state that to a new user.
If we imagine a new user as coming, not from cvs, but coming from
no revision control system, then it's less confusing to add one single
new state, (the "last committed" state), in addition to the "working
tree" state the user is familiar with.
Forcing the user to learn two instead of one is just plain harder,
(which is completely separate from git _allowing_ this extra state
once you learn it).
So if git is determined to just be harder to learn this way, then I
don't know what more I can do to help here.
I love git, and I think everyone should use it. I would just like to
help make it a bit easier for people to do that.
-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: Carl Worth @ 2006-11-30 19:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekn8s3$lh6$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Thu, 30 Nov 2006 19:47:16 +0100, Jakub Narebski wrote:
> while in git "git add" means "I want to add this file" (in the state
> it is now) and not "I want the system to 'know' about this file".
> And "commit" mean "Please commit the current 'known' state of all
> files (or/and the current state of files I mention here on the
> comand line)".
Yes. There is a logical explanation for what git does, and it is
self-consistent.
It just means that the user is _forced_ to pass file state across the:
"working tree" -> git
boundary at two different times with two different commands for the
very first commit the user makes. And the user _must_ understand that
this is a two-step process, (even though, without the "typo" in my
example above it would be natural to conclude the transition occurred
only during "commit").
See? Git _is_ harder to learn, and a user really cannot learn it
without being careful about the index right from the very beginning.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: v2.6.11 tag in kernel tree
From: Jon Smirl @ 2006-11-30 19:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0611300758290.3513@woody.osdl.org>
Thanks for the replies, I got it working. I'm trying to decipher the
changes a vendor made to 2.6.11 when they ported it to an ARM device
and peripherals.
It is the usual situation of releasing a GPL tarball without any
documentation as to what they changed.
--
Jon Smirl
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Linus Torvalds @ 2006-11-30 19:55 UTC (permalink / raw)
To: Carl Worth
Cc: Nicolas Pitre, Theodore Tso, Andreas Ericsson,
Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <87hcwgu5t1.wl%cworth@cworth.org>
On Thu, 30 Nov 2006, Carl Worth wrote:
>
> If the "create file; git add; edit file; git commit" confusion isn't
> blisteringly obvious to the git maintainers then I think I have to
> give up here.
>
> And this isn't just CVS-induced brain damage.
I'm sorry, but you are wrong.
It really _is_ CVS-induced brain damage, and I'm trying to teach you. You
can give up, but that's really "refuse to see the damage that systems like
RCS and CVS has done to the world"
The fundamental brain damage that CVS (and RCS, and SVN, and just about
anything else) has had is thinking that "filenames" (and sometimes this is
"fixed" to be "file ID's") are somehow special, and a totally separate
thing from "file contents".
Really. It's a BUG. It's a deficiency in CVS and friends. And it's a
deficiency that you have gotten so used to that you don't even see that
it's simply obviously NOT TRUE.
You _cannot_ have a filename without the contents of that filename. That
whole concept doesn't make sense, except in the twisted AND WRONG mental
model of "files have identities even without content".
The whole point of git is that it is about "project state" and the history
that binds those states together. People have kind of come to accept that,
and a lot of people realize what it means, but I don't think you've really
accepted what it means for something as simple as a "git add" command.
Again, totally ignore the index. Imagine that it doesn't exist. Imagine
that you never actually learnt about it, and that none of the
documentation ever mentions it, and just ask yourself:
"What does 'adding a file' really mean?"
I mean _really_. It cannot be about the "filename", because a filename
simply doesn't have any meaning alone. Remember what git is all about.
No, when you do a "git add", YOU DO NOT TALK ABOUT FILENAMES AT ALL.
NOT EVEN CLOSE!
No. Git is, and has always been, all about tracking project content. The
fact that CVS is crap, and thinks that "filenames" are special (and this
causes major problems when you do renames), and the fact that SVN is crap,
and things that "file identities" are special (and this causes major
problems when you split a file or when two files join) is very much about
THEIR F*CKING IDIOTIC FUNDAMENTAL BRAINDAMAGE!
So take five minutes to really think about that. Take an hour. Take a
week. Ponder it.
What does it mean to "add" something to a project? It has _nothing_ to do
with "filenames". Yeah, the filename obviously exists, but it's not
something that exists on its own. You add the ONLY thing that git tracks.
You add CONTENT.
When you do "git add file.c" you aren't adding a filename to the list of
files that git knows about. Not even CLOSE. No. You are really adding
_content_ to the project you are tracking. You haven't bound it to a
commit yet, but it's there. It's there both conceptually, and very much in
a real technical sense too (you've literally added the git object that
that file describes to the object database - the "commit" and "tree"
objects to tie it all together is just waiting to be added, but they
really just expose it - the actual file object has already been created
when you do "git add".)
So yes, you very much ARE talking about CVS braindamage. The reason why
git add file.c
echo New line >> file.c
git commit
commits the _old_ content, is very much because git is ALL ABOUT THE
CONTENT. It has _never_ been about filenames. And it _shouldn't_ be about
filenames, because that would be BUGGY AND BROKEN.
Sorry for shouting, but as long as you think "git add" adds a filename,
you're just not getting it. And I think it's really sad that you don't
even seem to understand that yes, this _is_ braindamage that has been
forced upon you by decades of mental rape done by bad source control
systems.
Please. File identities are _bad_ in the SVN kind of setting. The CVS kind
of "filename == file identity" is even _worse_, but it's still exactly the
same disease. It's the disease of thinking that metadata is somehow
"different" from real data, and that "files" have identities that are
somehow separate from the data they contain.
Face it, git is consistent, and if it acted the way you seem to expect it
to act, it would actually be a BUG. Exactly because you cannot and MUST
NOT think that "filename" is something that has meaning without "file
content" (or "file type" and "file permissions" - they all go together).
And notice? NONE OF THIS HAS ANYTHING AT ALL TO DO WITH 'INDEX'!! The
explanation above is not "this is how the index works". It's a much more
fundamnetal issue of getting the right mental model, where the only thing
that matters is contents.
So even without an index, "git add" should work the way it works, once you
can just let go of the broken model that is CVS.
Please. Join me, Luke. The power of the git side is stronger. I am your
father.
^ permalink raw reply
* Re: git blame [was: git and bzr]
From: Carl Worth @ 2006-11-30 19:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Joseph Wakeling, git
In-Reply-To: <Pine.LNX.4.64.0611301034420.3513@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]
On Thu, 30 Nov 2006 10:44:48 -0800 (PST), Linus Torvalds wrote:
>
> But that only exists for a couple of man-pages, and mostly for the simple
> ones at that. And a lot of the real examples would need "real data" to
> work on, so it can't easily be done as a trivial example in a man-page, it
> really needs a tutorial to "build up" to the situation where you can then
> explain with an example what to do.
Here's a crazy idea. How about a "git tutorial" builtin or "git
example" or something that would create a repository into some useful
state for demonstrating something.
I know that I'm regularly putting stuff into emails like:
mkdir gittest
cd gittest
git init-db
echo hello > hello
git add hello
git commit -m "add hello"
git checkout -b other
echo other > other
git add other
git commit -m "add other"
git checkout master
# OK, that was just setup, here's what I want to demonstrate
git pull . other
...
So maybe if there was a command to setup a standard example
repository, ("git boilerplate", "git sandbox", "git playground" ?),
then the documentation could use that to have full-fledged examples
without having to duplicate similar setup each time.
And then there could be a way for this command to also spit out the
commands it is using to reach some state so it could even serve as a
sort of self-documenting tutorial of some sort.
Anyone interested in exploring something like that?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git and bzr
From: Theodore Tso @ 2006-11-30 20:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Marko Macek, git, bazaar-ng
In-Reply-To: <456ECDAF.4050102@op5.se>
On Thu, Nov 30, 2006 at 01:25:19PM +0100, Andreas Ericsson wrote:
> Unless you do "git update-index" (and thus are already using the index)
> on any files, "git diff" shows you exactly the changes between your last
> commit and the working tree. There's nothing magic, odd or confusing
> about it, no matter which scm you come from.
Until you make the mistake of reading the git-diff man page, at which
point the novice git user runs screaming into the night...
Show changes between two ents, an ent and the working tree, an
ent 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 ents given to the command.
* When no <ent> is given, the working tree and the index file
is compared, using git-diff-files.
* When one <ent> is given, the working tree and the named tree
is compared, using git-diff-index. The option --cached can
be given to compare the index file and the named tree.
* When two <ent>s are given, these two trees are compared using
git-diff-tree.
Looking at the man page, it does raise one interesting question ---
So exactly what is the difference between Treebeard and Quickbeam?
And how many working trees do we need before we call it an Entmoot? :-)
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-30 20:09 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <20061130200122.GD10999@thunk.org>
Theodore Tso wrote:
> * When no <ent> is given, the working tree and the index file
> is compared, using git-diff-files.
* When no <tree-ish> is given, the working tree and the index file are
compared, using git-diff-files.
Use more modern git.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [BUG] git-fetch -k is broken
From: Nicolas Pitre @ 2006-11-30 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Actually, the .keep file is simply not removed as it should.
But first it appears that commit f64d7fd2 added an && on line 431 of
git-fetch.sh and that cannot be right. There is simply no condition for
not removing the lock file. It must be removed regardless if the
previous command succeeded or not. Junio?
Now for the actual problem. I instrumented git-fetch.sh to understand
what's going on as follows:
diff --git a/git-fetch.sh b/git-fetch.sh
index 8365785..042040e 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -397,10 +397,12 @@ fetch_main () {
continue ;;
keep)
pack_lockfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
+echo "a $pack_lockfile"
continue ;;
esac
found=
single_force=
+echo "b $pack_lockfile"
for ref in $refs
do
case "$ref" in
@@ -425,10 +427,13 @@ fetch_main () {
esac
done
local_name=$(expr "z$found" : 'z[^:]*:\(.*\)')
+echo "c $pack_lockfile"
append_fetch_head "$sha1" "$remote" \
"$remote_name" "$remote_nick" "$local_name" \
"$not_for_merge" || exit
- done &&
+echo "d $pack_lockfile"
+ done
+echo "e $pack_lockfile"
if [ "$pack_lockfile" ]; then rm -f "$pack_lockfile"; fi
) || exit ;;
esac
And performing a fetch -k produced the following output:
a .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
b .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
c .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
* refs/heads/next: fast forward to branch 'next' of
git://git.kernel.org/pub/scm/git/git
old..new: ede546b..c41921b
d .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
b .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
c .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
d .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
b .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
c .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
d .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
b .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
c .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
d .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
b .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
c .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
d .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
b .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
c .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
d .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
b .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
c .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
d .git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.keep
e
So....... How the heck could pack_lockfile become empty on the line with
the "e" mark?
$ /bin/sh --version
GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)
^ permalink raw reply related
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nicolas Pitre @ 2006-11-30 20:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carl Worth, Theodore Tso, Andreas Ericsson, Johannes Schindelin,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611301132350.3513@woody.osdl.org>
On Thu, 30 Nov 2006, Linus Torvalds wrote:
> What does it mean to "add" something to a project? It has _nothing_ to do
> with "filenames". Yeah, the filename obviously exists, but it's not
> something that exists on its own. You add the ONLY thing that git tracks.
>
> You add CONTENT.
>
> When you do "git add file.c" you aren't adding a filename to the list of
> files that git knows about. Not even CLOSE. No. You are really adding
> _content_ to the project you are tracking. You haven't bound it to a
> commit yet, but it's there. It's there both conceptually, and very much in
> a real technical sense too (you've literally added the git object that
> that file describes to the object database - the "commit" and "tree"
> objects to tie it all together is just waiting to be added, but they
> really just expose it - the actual file object has already been created
> when you do "git add".)
>
> So yes, you very much ARE talking about CVS braindamage. The reason why
>
> git add file.c
> echo New line >> file.c
> git commit
>
> commits the _old_ content, is very much because git is ALL ABOUT THE
> CONTENT. It has _never_ been about filenames. And it _shouldn't_ be about
> filenames, because that would be BUGGY AND BROKEN.
Great. But let me repeat my last question:
Would it make sense for "git add" to do the same as "git update-index"
on already tracked files? Given the explanation above this would make
100% sense to me.
Even for newbies this might help them understand the power of the index
with only one command. "You _add_ your changes together before you may
commit." That's simple to understand even for newbies. And then
they'll start using the power of the index even without realizing it.
But right now, doing "git add" on an already tracked file simply does
nothing. This is even worse than erroring out.
^ 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