* 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
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Linus Torvalds @ 2006-11-30 21:03 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Carl Worth, Theodore Tso, Andreas Ericsson, Johannes Schindelin,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611301521320.9647@xanadu.home>
On Thu, 30 Nov 2006, Nicolas Pitre wrote:
>
> 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.
Yeah, I think it would probably make sense. I also think it would make
sense to rename "update-index" entirely, or at least offer other names for
it (ie the "git resolved" suggestion).
In short - I agree that it's all just facets of the same thing: telling
git that some part of the working tree is now in a state ready to be
committed. Whether it's because we want to "add" content, or just mark it
as no longer having conflicts, or any other reason.
> But right now, doing "git add" on an already tracked file simply does
> nothing. This is even worse than erroring out.
Yeah, that's arguably a stupid thing to do ("you already added it, what do
you want me to do?") but the choice we use is probably the worst of the
three straightforward possibilities (ignore, update or error).
The _original_ "git add" was literally just this one-liner:
#!/bin/sh
git-update-index --add -- "$@"
which actually was better in this respect (it updated the content), but
that didn't do sub-directories, so this is arguable a bug introduced by
commit 37539fbd:
[PATCH] Improved "git add"
This fixes everybodys favourite complaint about "git add", namely that it
doesn't take directories.
which started using
git-ls-files --others -z -- "$@"
together with the exclude files to generate the list of files to add. At
that point, we lost files that already existed (since "--others" specifies
just files we don't know about).
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Jakub Narebski @ 2006-11-30 21:16 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611301253380.3513@woody.osdl.org>
Linus Torvalds wrote:
> The _original_ "git add" was literally just this one-liner:
>
> #!/bin/sh
> git-update-index --add -- "$@"
>
> which actually was better in this respect (it updated the content), but
> that didn't do sub-directories, so this is arguable a bug introduced by
> commit 37539fbd:
>
> [PATCH] Improved "git add"
>
> This fixes everybodys favourite complaint about "git add", namely that it
> doesn't take directories.
>
> which started using
>
> git-ls-files --others -z -- "$@"
>
> together with the exclude files to generate the list of files to add. At
> that point, we lost files that already existed (since "--others" specifies
> just files we don't know about).
So should we use then
git-ls-files --cached --others -z -- "$@"
in git-add?
I'm very much for having git-add, -rm, -mv and -resolved as porcelain
wrappers around git update-index, so there would be even less events
when you have to use this plumbish command directly.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Junio C Hamano @ 2006-11-30 21:19 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Linus Torvalds, Carl Worth, Theodore Tso, Andreas Ericsson,
Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0611301521320.9647@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> ... 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.
I think this makes sense and what we did in the original "git
add".
^ permalink raw reply
* Re: [BUG] git-fetch -k is broken
From: Junio C Hamano @ 2006-11-30 21:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611301441440.9647@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> 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?
True, but your "echo" patch breaks things even more -- when fast
forward check fails, it should cause the entire command should
report that with the exit status.
That suggests that we need to come up with a way to clean up
these .keep files some other way than just being one of the
command near the end. As to the mysterious "echo e <empty>"
I will not have chance to look at it myself until later today
(I'm at work now and it is not my git day today).
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-30 21:22 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Shawn Pearce, Git List
In-Reply-To: <1164910560.4724.117.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> On Sat, 2006-11-25 at 21:58, Junio C Hamano wrote:
>> > ...
>> > 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,...
>> ...
>> 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.
Think of it not as a difference between you and Shawn, but as a
difference in me back then and me now, who finally saw the light
in your revelation after gaining a year's worth of experience ;-).
Seriously, I did not ignore it, and I think some of your other
comments in the message contributed to improved documentation.
When your message was posted, the issue Shawn raised in his
message was not so prominent, because people did not even get
that "Pull: refs/heads/pu:refs/heads/pu" line in their remotes/
file by default back then. It was back in 0.99.9 era and a few
days after your message, a patch was posted to put more than
just the 'master' mapping in the remotes/ file clone creates.
It became an issue after that change but we lacked the resources
nor sense of urgency to do the out-of-band stuff, as we were
busy working on other things.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Robert Shearman @ 2006-11-30 21:33 UTC (permalink / raw)
To: Carl Worth
Cc: Nicolas Pitre, Linus Torvalds, Theodore Tso, Andreas Ericsson,
Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <87hcwgu5t1.wl%cworth@cworth.org>
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. 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.
>
Exactly. We had a tutorial for the project I contribute to (admittedly
the initial users were all used to how CVS worked) and while a number of
people got the concept of the index and were fairly happy with it, it
did add to the confusion of the tutorial, so now it doesn't mention the
index at all.
The tutorial introduced it as a staging area for commits, but the
trouble is that once you work like this you have to remember that
"git-diff" won't show you what will be committed, so you have to use
"git-diff-index" as well. If you get them mixed up then you end up
committing the wrong thing.
Here's a selected list of the commands introduced in the tutorial,
without mentioning the index:
git diff
git commit -a
git commit <changed-files>
git reset HEAD^
git cherry-pick
Here would be the same entries, but introducing the index too:
git-update-index
git diff
git diff-index
git commit
git commit -a
git commit <changed-files>
git reset HEAD^
git reset --soft HEAD^
git cherry-pick
git cherry-pick -n
The tutorial then goes from having ~12 common commands to learn up to ~17.
> 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).
Having the index exposed for even simple operations means that the user
has to initially learn three states instead of two. The worst thing
about the index is that it is a limbo state. The committed content is in
the history and can be viewed by gitk (and other tools that the user
will be introduced to later) and the working tree is exactly what the
user sees in their editor. Having a hidden state isn't very good from an
HCI point of view.
Once you understand the concept of the index, it is very useful.
However, new users should be shielded from it if at all possible.
I'm not advocating making "git-commit" equal to "git-commit -a" as I've
been frustrated by command's semantics changing in git before. I can
understand long-time git users would automatically try to use
"git-commit" to just commit their index and get annoyed if it did
something unexpected. Therefore, I would advocate there being no default
behaviour for "git-commit" except for displaying a help message, and
making previous "git-commit" users now use "git-commit -i".
--
Rob Shearman
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Carl Worth @ 2006-11-30 21:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eknhjr$nce$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]
On Thu, 30 Nov 2006 Linus Torvalds wrote:
> On Thu, 30 Nov 2006, Nicolas Pitre wrote:
> >
> > 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.
>
> Yeah, I think it would probably make sense. I also think it would make
> sense to rename "update-index" entirely, or at least offer other names for
> it (ie the "git resolved" suggestion).
On Thu, 30 Nov 2006 22:16:29 +0100, Jakub Narebski wrote:
> I'm very much for having git-add, -rm, -mv and -resolved as porcelain
> wrappers around git update-index, so there would be even less events
> when you have to use this plumbish command directly.
I'm happy with the direction of having several commands that take the
place of update-index, each with its own name oriented toward what the
user wants to do.
Obviously, "add", "mv", and "rm" have obvious places where the user
wants to use them.
There's the merge case where "resolve" and "resolved" have both been
floated as possible names.
It might even make sense to invent one more name for the case where
the user wants to inform git that a file has been edited and that git
should accept the new contents. It's the sort of "note that file is
edited" operation that could be recommended to the user with "add; fix
typo; commit" confusion.
Sure, "add" could be used again, and "update-index" clearly _works_
but it's a rather ugly name, (and already has "plumbing" functionality
like --add and --remove that we don't want here).
If "resolved" is the name for the new command, then "edited" might
work, but I think these adjectives don't work well next to the more
active verbs that git normally accepts, (and yes, "mv" and "rm" are
verbs even if horribly mangled spellings).
So I'd vote for "resolve" along with something else for the
mark-as-edited case. Maybe "refresh"? That's the best I've thought of
so far. Anyone else have a better suggestion? It does clash with the
separate notion of "git update-index --refresh" which is a bit
annoying. Any other suggestions for this?
-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: Jakub Narebski @ 2006-11-30 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <456F4E38.50001@codeweavers.com>
Robert Shearman wrote:
> Having the index exposed for even simple operations means that the user
> has to initially learn three states instead of two. The worst thing
> about the index is that it is a limbo state. The committed content is in
> the history and can be viewed by gitk (and other tools that the user
> will be introduced to later) and the working tree is exactly what the
> user sees in their editor. Having a hidden state isn't very good from an
> HCI point of view.
Index is accessible, just like committed contents. The fact that gitk, qgit,
git-gui doesn't display state of index is their limitation.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Michael K. Edwards @ 2006-11-30 21:41 UTC (permalink / raw)
To: Carl Worth; +Cc: Jakub Narebski, git
In-Reply-To: <878xhsty3t.wl%cworth@cworth.org>
On 11/30/06, Carl Worth <cworth@cworth.org> wrote:
> So I'd vote for "resolve" along with something else for the
> mark-as-edited case. Maybe "refresh"? That's the best I've thought of
> so far. Anyone else have a better suggestion? It does clash with the
> separate notion of "git update-index --refresh" which is a bit
> annoying. Any other suggestions for this?
git mark
and git add becomes just a synonym for git mark.
Cheers,
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Carl Worth @ 2006-11-30 21:50 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: Jakub Narebski, git
In-Reply-To: <f2b55d220611301341n45c45506rca312dfa8ee6f795@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
On Thu, 30 Nov 2006 13:41:37 -0800, "Michael K. Edwards" wrote:
>
> git mark
I actually thought of that. But compared to "refresh" it sounds more
like something that suggests marking a file path rather than copying
contents, so our dark lord might not approve of the wrong ideas it
might allow to persist in brain-damaged heads.
It is nice and short, which is a bonus though.
-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: Jakub Narebski @ 2006-11-30 21:58 UTC (permalink / raw)
To: Carl Worth; +Cc: Michael K. Edwards, git
In-Reply-To: <8764cwtxhm.wl%cworth@cworth.org>
Dnia czwartek 30. listopada 2006 22:50, Carl Worth napisał:
> On Thu, 30 Nov 2006 13:41:37 -0800, "Michael K. Edwards" wrote:
>>
>> git mark
>
> I actually thought of that. But compared to "refresh" it sounds more
> like something that suggests marking a file path rather than copying
> contents, so our dark lord might not approve of the wrong ideas it
> might allow to persist in brain-damaged heads.
>
> It is nice and short, which is a bonus though.
What about "git update"? "git add" would also work, I think.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Josef Weidendorfer @ 2006-11-30 22:07 UTC (permalink / raw)
To: Carl Worth; +Cc: Jakub Narebski, git
In-Reply-To: <878xhsty3t.wl%cworth@cworth.org>
On Thursday 30 November 2006 22:37, Carl Worth wrote:
> So I'd vote for "resolve" along with something else for the
> mark-as-edited case. Maybe "refresh"? That's the best I've thought of
> so far. Anyone else have a better suggestion?
git stage
^ permalink raw reply
* [RFC] git-add update with all-0 object
From: Daniel Barkalow @ 2006-11-30 22:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
One thing that I think is non-intuitive to a lot of users (either novice
or who just don't do it much) is that it matters where in the process you
do "git add <path>" if you're also changing the file. Even if you
understand the index, you may not realize (or may not have internalized
the fact) that what git-add does is update the index with what's there
now.
I think the more obvious behavior is to have it record the fact that you
want to have the path tracked, but require one of the usual updating
mechanisms to get a particular content into the index.
This should be pretty simple to implement: use --cacheinfo 0 0 $path
instead of --add -- $path, and teach programs that look at the objects
recorded in the index (rather than just hashes or other info) about all-0
hashes meaning "but no content there". write-tree would probably just
skip the entry (and then you could add a file, but still produce commits
without it until you actually do either an update-index explicitly or one
of the commit option sets that updates it); diff would treat it as empty;
checkout would ignore it.
-Daniel
^ permalink raw reply
* Re: git blame [was: git and bzr]
From: Johannes Schindelin @ 2006-11-30 22:17 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Joseph Wakeling, git
In-Reply-To: <87d574u2tl.wl%cworth@cworth.org>
Hi,
On Thu, 30 Nov 2006, Carl Worth wrote:
> 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.
That sounds fine! Actually, it should be very simple to turn the tutorial
into such a script, displaying the command with an explanation, and
executing the command. It could even call gitk from time to time, so the
user can form a mental model of the ancestor graph.
Ciao,
Dscho
^ permalink raw reply
* Re: Getting CVS and Git to play nicely in the same box
From: Robin Rosenberg @ 2006-11-30 22:21 UTC (permalink / raw)
To: kernel-hacker; +Cc: Git Mailing List
In-Reply-To: <1164890354.21950.92.camel@okra.transitives.com>
torsdag 30 november 2006 13:39 skrev Alex Bennee:
> Hi,
>
> I'm trying to get a setup where I can use git for my day to day coding
> on problems but still mirror a CVS repo. The situation is muddied
> slightly by the way we manage changes in our CVS repository and
> baselines.
>
> The CVS manner of working means we create a branch at a given point to
> do work on it:
>
> BL1_CH2
> /
> /
> BL1_CH1
> BL1---/
>
> And then in the meantime a new baseline may be released:
>
>
> BL2 BL1_CH2
>
> | /
> | BL1_CH1
>
> BL1--/
>
> So we employ the "cvs -q update -dP -j BL1 -j BL2" on our development
> branch
>
> BL2_CH2
> /
> BL2 BL1_CH2
>
> | /
> | BL1_CH1
>
> BL1--/
>
> I want to mirror this sort of behaviour it git (basically making the
> cvs -j -j operation a git merge, separate from the normal development
> track). I however also need to maintain the CVS meta-data so when I get to
> given points I can commit my work into the main development server.
>
> I can set up a git repo that ignore all the CVS gubbins with exclude info
> but the CVS metadata gets in the way. I think I have to maintain two git
> repos, one that tracks the baseline and one which is a clone (which can
> then pull updates) but has the CVS meta data for my development branch.
You don't need to use GIT to track metadata (I asume you mean CVS/Entries) is
not necessary. Use a plain CVS checkout for that and cvsexportcommit to it.
> However CVS does seem to get very confused when the world moves under it
> when you switch branches in GIT.
Exaktly. Forget about it, it won't work and there is a simpler solution.
> Has anyone successfully set up such a working environment? Can anyone offer
> any tips on how to make it all work nicely?
My setup is like this:
- A tracking repo on a server runs git-cvsimport every night.
- I pull from the tracking repo
- I have a CVS checkout for the branch I'm interested in committing to
- Then I use cvsexportcommit to export changes back to CVS. Actuallly I use a
small script that runs cvs update and then exports the changes defined by a
named commit so I say "tocvs a-commitid--tag-or-stgit-patch-name".
Since I use StGit I get no problem from my changes coming back through the
cvsimport executed on the server. StGit makes the patches empty when my own
code returns from CVS.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nicolas Pitre @ 2006-11-30 22:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Carl Worth, Theodore Tso, Andreas Ericsson,
Johannes Schindelin, git
In-Reply-To: <7vhcwgiqer.fsf@assigned-by-dhcp.cox.net>
On Thu, 30 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > ... 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.
>
> I think this makes sense and what we did in the original "git
> add".
Wonderful! We might be converging to something then.
Because, conceptually, it then becomes much easier to tell newbies about
the index as follows (this could be pasted in a tutorial somewhere):
Contrary to other SCMs, with GIT you have to explicitly "add" all
the changes you want to commit together. This can be done in a few
different ways:
1) By using "git add <file_spec...>"
This can be performed multiple times before a commit. Note that
this is not only for adding new files. Even modified files must be
added to the set of changes about to be committed. The "git
status" command gives you a summary of what is included so far for
the commit. When done you should use the "git commit" command to
make it real.
Note: don't forget to "add" a file again if you modified it after
the first "add" and before "commit". Otherwise only the previous
"added" state of that file will be committed.
2) By using "git commit -a" directly
This is a quick way to automatically "add" all modified files to
the set of changes and perform the actual commit without having to
separately "add" them. This will not "add" new files -- those
files still have to be added explicitly before performing a commit.
Here's a twist. If you do "git commit <file1> <file2> ..." then
only the changes belonging to those explicitly specified files will
be committed, entirely bypassing the current "added" changes. Those
"added" changes will still remain available for a subsequent commit.
There is a twist about that twist: if you do "git commit -i <file>..."
then the commit will consider changes to those specified files
_including_ all "added" changes so far.
But for instance it is best to only remember "git add" + "git
commit" and/or "git commit -a".
Doesn't it sounds nice? The index is being introduced up front without
even mentioning it, and I think the above should be fairly palatable to
newbies as well. Would only lack some enhancements to the commit
template and the "nothing to commit" message so the user is cued about
the fact that "current changeset is empty -- don't forget to 'git add'
modified files, or use 'git commit -a'".
What do you think?
^ permalink raw reply
* Re: git blame [was: git and bzr]
From: J. Bruce Fields @ 2006-11-30 22:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, Linus Torvalds, Joseph Wakeling, git
In-Reply-To: <Pine.LNX.4.63.0611302314320.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 30, 2006 at 11:17:12PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 30 Nov 2006, Carl Worth wrote:
>
> > 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.
>
> That sounds fine! Actually, it should be very simple to turn the tutorial
> into such a script, displaying the command with an explanation, and
> executing the command. It could even call gitk from time to time, so the
> user can form a mental model of the ancestor graph.
Currently tutorial.txt doesn't work like that--there are places where it
just tells the user to edit a file, or make a few commits, without
listing commands to do so. It also isn't linear. That could all be
"fixed", but I think the result would just make it more tedious.
But I agree that a "git tutorial" command to set up a canonical example
repository might be fun.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Johannes Schindelin @ 2006-11-30 22:25 UTC (permalink / raw)
To: Carl Worth; +Cc: Jakub Narebski, git
In-Reply-To: <878xhsty3t.wl%cworth@cworth.org>
Hi,
On Thu, 30 Nov 2006, Carl Worth wrote:
> It might even make sense to invent one more name for the case where
> the user wants to inform git that a file has been edited and that git
> should accept the new contents. It's the sort of "note that file is
> edited" operation that could be recommended to the user with "add; fix
> typo; commit" confusion.
I suggest "commit". How about this: after editing the file, you tell git
that you finished editing it by doing
git commit the-edited-file.txt
Hmmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Johannes Schindelin @ 2006-11-30 22:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Carl Worth, Michael K. Edwards, git
In-Reply-To: <200611302258.09523.jnareb@gmail.com>
Hi,
On Thu, 30 Nov 2006, Jakub Narebski wrote:
> What about "git update"?
... and suffer another thread a la "pull/merge"? Please no.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nicolas Pitre @ 2006-11-30 22:31 UTC (permalink / raw)
To: Carl Worth; +Cc: Jakub Narebski, git
In-Reply-To: <878xhsty3t.wl%cworth@cworth.org>
On Thu, 30 Nov 2006, Carl Worth wrote:
> It might even make sense to invent one more name for the case where
> the user wants to inform git that a file has been edited and that git
> should accept the new contents. It's the sort of "note that file is
> edited" operation that could be recommended to the user with "add; fix
> typo; commit" confusion.
>
> Sure, "add" could be used again, and "update-index" clearly _works_
> but it's a rather ugly name, (and already has "plumbing" functionality
> like --add and --remove that we don't want here).
I disagree. "add" is beautiful. It is short, easy to remember, and
transcend pretty much what the index is all about. And just because
"add" and "edited" can be made into the same command is a pretty damn
good reason not to create a separate command.
You "add" changes to the changeset then you commit that changeset.
No need to care whether or not this is a new file, an edited file, etc.
^ permalink raw reply
* Re: [RFC] git-add update with all-0 object
From: Johannes Schindelin @ 2006-11-30 22:32 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0611301634080.20138@iabervon.org>
Hi,
On Thu, 30 Nov 2006, Daniel Barkalow wrote:
> I think the more obvious behavior is to have it record the fact that you
> want to have the path tracked, but require one of the usual updating
> mechanisms to get a particular content into the index.
I fear that this is just your being used to the CVS mindset. Please see
http://article.gmane.org/gmane.comp.version-control.git/32792 for details.
Hth,
Dscho
^ permalink raw reply
* Re: [RFC] git-add update with all-0 object
From: Nicolas Pitre @ 2006-11-30 22:34 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0611301634080.20138@iabervon.org>
On Thu, 30 Nov 2006, Daniel Barkalow wrote:
> One thing that I think is non-intuitive to a lot of users (either novice
> or who just don't do it much) is that it matters where in the process you
> do "git add <path>" if you're also changing the file. Even if you
> understand the index, you may not realize (or may not have internalized
> the fact) that what git-add does is update the index with what's there
> now.
And actually I think this is a good thing. This is what makes the index
worth it. Better find a way to make it obvious to people what's
happening.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nicolas Pitre @ 2006-11-30 22:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.63.0611302324370.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 30 Nov 2006, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 30 Nov 2006, Carl Worth wrote:
>
> > It might even make sense to invent one more name for the case where
> > the user wants to inform git that a file has been edited and that git
> > should accept the new contents. It's the sort of "note that file is
> > edited" operation that could be recommended to the user with "add; fix
> > typo; commit" confusion.
>
> I suggest "commit". How about this: after editing the file, you tell git
> that you finished editing it by doing
>
> git commit the-edited-file.txt
>
> Hmmm?
Sure. ;-)
^ permalink raw reply
* Re: git blame
From: Junio C Hamano @ 2006-11-30 22:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Joseph Wakeling, Carl Worth
In-Reply-To: <Pine.LNX.4.63.0611302314320.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 30 Nov 2006, Carl Worth wrote:
>
>> 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.
>
> That sounds fine! Actually, it should be very simple to turn the tutorial
> into such a script, displaying the command with an explanation, and
> executing the command. It could even call gitk from time to time, so the
> user can form a mental model of the ancestor graph.
Doesn't one of our existing t/ scripts do that?
^ 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