* v2.6.11 tag in kernel tree
From: Jon Smirl @ 2006-11-30 4:02 UTC (permalink / raw)
To: Git Mailing List
Using this tree git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
These two tags appear to be pointing to a tree instead of a commit.
v2.6.11
v2.6.11-tree
I'm trying to check out v2.6.11 so that I can figure out the changes a
vendor made to it.
jonsmirl@jonsmirl:/extra/linux$ git checkout -b microcross v2.6.11
Cannot switch branch to a non-commit.
I can checkout the other tags without problem.
What's the secret to checking out 2.6.11?
--
Jon Smirl
^ permalink raw reply
* Re: v2.6.11 tag in kernel tree
From: Junio C Hamano @ 2006-11-30 4:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910611292002o289dc4d1u7bde2d457fa97d73@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> I'm trying to check out v2.6.11 so that I can figure out the changes a
> vendor made to it.
>
> jonsmirl@jonsmirl:/extra/linux$ git checkout -b microcross v2.6.11
> Cannot switch branch to a non-commit.
Sorry, you cannot check it out directly, and there is no easy
way to start a new branch from a bare tree.
I would create a temporary branch from any commit and reset the
working tree with it.
git checkout -b temp master
git read-tree -m -u v2.6.11-tree
One BIG caveat is that this in state, only your index and the
working tree can be trusted. The history of temp branch does
not have anything to do with v2.6.11 -- a bare tree object does
not have any history behind it (or on top of it, for that
matter).
A slightly more elaborate way would be
$ git checkout -b v2.6.11-phoney $(echo 'phoney v2.6.11' |
git commit-tree v2.6.11-tree^{tree})
to create a parentless commit that has v2.6.11-tree, and make
that your current branch. But again this commit does not have
any relationship in history with the development line that leads
to v2.6.19 just released.
You could graft it as the parent of v2.6.12-rc2 (the first
commit in git era) after doing the above:
$ parent=$(git-rev-parse v2.6.11-phoney^0)
$ commit=$(git-rev-parse v2.6.12-rc2^0)
$ echo $commit $parent >>.git/info/grafts
and pretend as if v2.6.12-rc2 is a child of v2.6.11-phoney.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Seth Falcon @ 2006-11-30 5:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkluoulf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> My time is better spent on _listening_ to people who might want to
> make convincing arguments to influence what I will end up deciding
> (the final decision will be mine anyway).
So I will add my $0.02:
Summary: leave git-commit as-is
I think the intimidation factor of the index is overstated. A
scratch working area is a natural concept -- that's what people do
who don't even _know_ what an scm is. I agree with Junio's
description of commit -a as default breaking the mental model.
I've played with three distributed scm: tla, hg, and git. I've
stuck with git because, in part, it helped me to learn its more
advanced features -- not because it was easiest to use intially out
of the box. And if I'm not going to get something more than cvs or
svn gives me, what's the point of switching in the first place?
+ seth
^ permalink raw reply
* Unprivileged User
From: Ed @ 2006-11-30 5:54 UTC (permalink / raw)
To: git
Hi, I'm new to git. Just got everything setup and imported a new project.
From gitweb it says that my git project's owner is: Unprivileged User
Should I be worried about this when I begin using this git project with others?
How would I resolve this, to make the owner as the name I set in my
~/.gitconfig, or is there something I didn't read in the docs?
Thanks, beside this small glitch, git has been great.
^ permalink raw reply
* Re: git and bzr
From: Raimund Bauer @ 2006-11-30 6:59 UTC (permalink / raw)
To: Carl Worth; +Cc: git, bazaar-ng
In-Reply-To: <87bqmpvlxf.wl%cworth@cworth.org>
* Carl Worth wrote, On 30.11.2006 01:05:
> Let's help people do exactly that by making the behavior of "git
> commit -a" be the default for "git commit".
>
Maybe we could do that _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?
> -Carl
--
best regards
Ray
^ permalink raw reply
* Re: git and bzr
From: Carl Worth @ 2006-11-30 7:17 UTC (permalink / raw)
To: Raimund Bauer; +Cc: git
In-Reply-To: <456E8147.9070304@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]
On Thu, 30 Nov 2006 07:59:19 +0100, Raimund Bauer wrote:
> * Carl Worth wrote, On 30.11.2006 01:05:
> > Let's help people do exactly that by making the behavior of "git
> > commit -a" be the default for "git commit".
> >
> Maybe we could do that _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?
I thought of that tonight and almost suggested it myself. It would be
an attempt to satisfy both "sides" of the debate without either side
having to fight with a default they didn't like or configure it away.
I did wonder if the powers that be would find it a bit too magic, (the
problem with magic things is that they can sometimes be quite
confusing when they don't do exactly what you want).
But this might just work. It wouldn't be too bad to document, (we
already have several commands that change slightly if the index
doesn't match, (often by just refusing to do anything in a dirty
tree)).
And, significantly this would allow for documenting the simple
sequence of:
# edit file
git commit
in the tutorial while also allowing what Junio wanted:
git update-index file
git commit
with the behavior of, ("I already said I wanted to do a staged commit
when I explicitly updated the index, so don't make me say anything
special again when I go to commit").
Can we really get the best of both worlds here?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-merge: preserve and merge local changes when doing fast forward
From: Carl Worth @ 2006-11-30 7:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wnlmyba.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
On Wed, 29 Nov 2006 19:02:33 -0800, Junio C Hamano wrote:
> The idea and the logic are identical to what "checkout -m" does
> when switching the branches. Instead of refusing the two-way
> merge, perform the three-way merge between the old head, the
> working tree and the new head, and leave the (potentially
> conflicted) merge result in the working tree.
This looks very appealing to me. I know I've often been frustrated
when git refuses to fast-forward just because I have dirty state, (and
stashing the diff manually into a patch file, then re-applying it
after fast forward is really annoying---getting work done in spite of
the tool and not because of it).
> * I am not sure if this is worth doing in general; it can leave
> a huge mess if the conflict with the merge and the local
> change is too extensive and does not give a good way to
> recover from it,
As I said above it seems very reasonable to me. As for the problem you
mention here, isn't "no good way to recover from it" the real problem,
and not this merge possibility? And is there enough information in the
index file such that one could implement a way to recover from this?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git and bzr
From: Alan Chandler @ 2006-11-30 8:31 UTC (permalink / raw)
To: git
In-Reply-To: <456E8147.9070304@gmx.net>
On Thursday 30 November 2006 06:59, Raimund Bauer wrote:
> Maybe we could do that _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?
>
I have been(silently) following the git commit discussion and started being
fully on the side of git commit -a being the default, but was slowly moving
over towards the git commit -i being the default camp.
This post seems like a Eureka moment - chew over the problem long enough and
someone comes in from left field with an off the wall remark that suddenly
clarifies everything.
--
Alan Chandler
^ permalink raw reply
* Re: [PATCH 2/2] Don't require config file for "stg mail"
From: Catalin Marinas @ 2006-11-30 8:32 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1164842841.23643.28.camel@dv>
On 29/11/06, Pavel Roskin <proski@gnu.org> wrote:
> On Wed, 2006-11-29 at 16:29 +0000, Catalin Marinas wrote:
> > Your patch uses the author of the patch which can be different from
> > the person sending the e-mail. It could indeed use the author from GIT
> > variables or configuration (not the patch author) and I already have a
> > patch from Karl Hasselström for this (which I haven't found the time
> > to check properly).
>
> The funny thing it, GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL are only used
> in the code to determine the author of the patch.
Yes, but only for a newly created patch. If you import a patch from an
mbox or e-mail or simply pass the --author option to "new", the author
will be different.
--
^ permalink raw reply
* Re: git and bzr
From: Nguyen Thai Ngoc Duy @ 2006-11-30 9:01 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Carl Worth, git
In-Reply-To: <456E8147.9070304@gmx.net>
On 11/30/06, Raimund Bauer <ray007@gmx.net> wrote:
> * Carl Worth wrote, On 30.11.2006 01:05:
> > Let's help people do exactly that by making the behavior of "git
> > commit -a" be the default for "git commit".
> >
> Maybe we could do that _only_ if the index matches HEAD, and otherwise
> keep current behavior?
I hate the if clause. Suppose I prefer update-index way, I would have
to check whether HEAD matches index everytime I do a commit to make
sure it won't do the other way.
Either -a or -i is the default, not if please.
By the way I do use the update-index way, but vote -a by default. I
don't mind adding " -i" after every commit commands.
--
^ permalink raw reply
* Re: Unprivileged User
From: Jakub Narebski @ 2006-11-30 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <2b9545a0611292154r4334d1afn1f49bbd3be2c3374@mail.gmail.com>
Ed wrote:
> Hi, I'm new to git. Just got everything setup and imported a new project.
>
> From gitweb it says that my git project's owner is: Unprivileged User
>
> Should I be worried about this when I begin using this git project with others?
>
> How would I resolve this, to make the owner as the name I set in my
> ~/.gitconfig, or is there something I didn't read in the docs?
>
> Thanks, beside this small glitch, git has been great.
Actually gitweb uses uid/user the repository (the $GIT_DIR), unless you
provide it with an index file. The simplest way is to click on "TXT" link
in projects list page, save it somewhere, edit it, and recompile gitweb
with this file as GITWEB_LIST (see README):
make ... GITWEB_LIST=<index> gitweb/gitweb.cgi
(or just edit gitweb.cgi or gitweb_conf.perl setting $projects_list
to this file).
Perhaps gitweb should use user.name from the repository instead...
P.S. Please reply also to git mailing list
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git and bzr
From: Alan Chandler @ 2006-11-30 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0611300101s51a53b75lc7e771b067ba6e33@mail.gmail.com>
On Thursday 30 November 2006 09:01, Nguyen Thai Ngoc Duy wrote:
> On 11/30/06, Raimund Bauer <ray007@gmx.net> wrote:
> > * Carl Worth wrote, On 30.11.2006 01:05:
> > > Let's help people do exactly that by making the behavior of "git
> > > commit -a" be the default for "git commit".
> >
> > Maybe we could do that _only_ if the index matches HEAD, and otherwise
> > keep current behavior?
>
> I hate the if clause. Suppose I prefer update-index way, I would have
> to check whether HEAD matches index everytime I do a commit to make
> sure it won't do the other way.
No you won't.
If you don't use update-index, then index will match HEAD and you will commit
changes in the working tree. That is the way for newbies
As soon as you do the first update-index the index will no longer match HEAD,
so commit will do the same as it does now.
And if you are not sure which you have done then presumably you do what you do
now, or git commit -a or git commit -i as you need.
--
Alan Chandler
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-30 9:35 UTC (permalink / raw)
To: git
In-Reply-To: <200611300930.33537.alan@chandlerfamily.org.uk>
Alan Chandler wrote:
> And if you are not sure which you have done then presumably you do what you do
> now, or git commit -a or git commit -i as you need.
By the way, short option -i is not --index but --include (i.e. commit
both changes in index and files mentioned on command line). Perhaps -I?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Unprivileged User
From: Junio C Hamano @ 2006-11-30 9:39 UTC (permalink / raw)
To: Ed; +Cc: jnareb, git
In-Reply-To: <ekm6si$psp$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Ed wrote:
>
>> From gitweb it says that my git project's owner is: Unprivileged User
> ...
> Actually gitweb uses uid/user the repository (the $GIT_DIR), unless you
> provide it with an index file.
This is a shot in the dark, but by any chance is this repository
owned by nobody, which is mapped to "Unprivileged User" by
/etc/passwd? Googling for "Unprivileged User" and "getpwent"
tells me that on OSX boxes nobody seems to map to that Gecos
name.
To explicitly set the names of list of projects and their
owners, set up $projects_list text file. A hint for its format
is found around line 1111 in gitweb/gitweb.perl script.
Hopefully somebody has documentation for gitweb configuration
so that people do not have to refer to the source to find things
out, but I do not know of a URL offhand...
^ permalink raw reply
* Re: git and bzr
From: Steven Grimm @ 2006-11-30 9:39 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200611300930.33537.alan@chandlerfamily.org.uk>
Alan Chandler wrote:
> No you won't.
>
> If you don't use update-index, then index will match HEAD and you will commit
> changes in the working tree. That is the way for newbies
>
> As soon as you do the first update-index the index will no longer match HEAD,
> so commit will do the same as it does now.
>
> And if you are not sure which you have done then presumably you do what you do
> now, or git commit -a or git commit -i as you need.
Plus, one assumes, the git-generated comments in the commit message will
tell you what kind of commit it has decided to do.
I like this suggestion a lot. Thinking back over my git usage recently,
which has included both styles of commits (though mostly -a ones), I
think this would have done the right thing by default in every case.
^ permalink raw reply
* Re: git and bzr
From: Junio C Hamano @ 2006-11-30 10:01 UTC (permalink / raw)
To: jnareb; +Cc: Alan Chandler, git
In-Reply-To: <ekm8ig$usu$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, short option -i is not --index but --include (i.e. commit
> both changes in index and files mentioned on command line). Perhaps -I?
Just in case nobody noticed after looking at the first part of
my patch a few nights ago, --include happens to mean exactly
what --index would mean anyway.
By default, "git commit" without parameter does "make a commit
out of the index". With paths, it used to mean "oh, by the way,
I forgot to run update-index on these paths, so could you please
do that for me now before you make the commit", and has been
that way for a long time.
Much later, people from CVS background wanted to say "edit foo
bar; git update-index bar; git commit foo" to mean "I might have
done something to the index, but I do not want to care about it
now -- please make a commit that includes only the changes to
bar and I do not want the changes to foo included in the
commit". Somehow we ended up introducing that twisted semantics
and that was where --only came from, which unfortunately later
became the default (and I already said that I realize this was a
big mistake).
While we transitioned to switch the default, we first came up
with a name to ask for the traditional semantics (--include),
warned people who gave paths without either -i nor -o that the
--include semantics is still the default but would change soon
(which meant that -i was a no-op back then), then switched the
default and we now warn that the default is now -o (so now -o is
a no-op) when people give only paths without -i nor -o.
Currently (that is, without the first part of my two patches),
"git commit -i" and "git commit -o" without paths refuse to
work, saying that these modes of operation do not make sense
without any path.
However, you can think of the simplest "commit the current
index" semantics as a degenerated case of saying "oh, by the
way, please run update-index on these paths I forgot to do
earlier before you make the commit" and giving no paths.
So "git commit -i" without paths _could_ mean "commit the index
as is" very naturally without introducing an independent switch
with different name. That is what the first part of my two
patches to Carl does.
^ permalink raw reply
* Re: git and bzr
From: Johannes Schindelin @ 2006-11-30 10:19 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Carl Worth, git, bazaar-ng
In-Reply-To: <456E8147.9070304@gmx.net>
Hi,
On Thu, 30 Nov 2006, Raimund Bauer wrote:
> * Carl Worth wrote, On 30.11.2006 01:05:
> > Let's help people do exactly that by making the behavior of "git
> > commit -a" be the default for "git commit".
> >
> Maybe we could do that _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?
So many people spoke for it, it's time I crash the wedding.
From a usability viewpoint, it is a horrible convention. The user has to
remember too much of the side effects to handle the commit operation.
The function of the program would no longer be dependent on the command
line arguments and your config, but _also_ on something as volatile as
the index.
You would literally end up asking "did I change the index?" _everytime_
before you commit.
And remember, even a simple "git add" changes the index! (Why it does is
brutally clear once you grasp the concept of the staging area.)
Worse, doing a "git commit --amend" should _not_ automatically add "-a"
_even_ if the index matches the HEAD, since it is quite possible that you
had a typo in the message you want to fix up. And quite possibly other
options would not want that either.
But here's an idea: tell the user that she has to tell git-commit which
files she wants committed. Yes! That's it. Just tell it the friggin'
files. And if you are a lazy bum, and want to commit _all_ modified
files, git has a nice shortcut for ya: "-a".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Johannes Schindelin @ 2006-11-30 10:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Carl Worth, Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.64.0611291859070.3513@woody.osdl.org>
Hi,
On Wed, 29 Nov 2006, Linus Torvalds wrote:
> So where doing the "git apply --index" thing is great is when you see a
> patch that has some obvious deficiency that makes you not want to commit
> it directly, but add some fixup of your own.
An obvious deficiency would also be the presence of hundreds of debug
quirks I had to introduce to find the bug which I finally fixed. But I do
not want to commit, because it is such a mess. So: into the index, ye
files.
Now I can clean up everything I introduced to find the bug. If the result
does not work as expected? "git diff"!
But now that I cleaned up the mess, I find that there is a more elegant
way to solve the problem. Into the index, ye files! Clicketyclick, if I
mess up, I always have the state in the index!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: preserve and merge local changes when doing fast forward
From: Johannes Schindelin @ 2006-11-30 10:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wnlmyba.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 29 Nov 2006, Junio C Hamano wrote:
> Perhaps we would want a new option to git-merge to allow preserving the
> local changes, but the obvious candidate -m is taken for something else
> per recent popular request X-<...
How about "-k|--keep-changes" or "-l|--local-changes", or
"-p|--preserve-changes"?
BTW from a user's perspective, this operation _is_ a merge, not a
checkout. So, IMHO the compatibility with that rarely used option of
git-checkout is neglectable.
Ciao,
^ permalink raw reply
* Re: Unprivileged User
From: Pazu @ 2006-11-30 10:50 UTC (permalink / raw)
To: git
In-Reply-To: <ekm6si$psp$1@sea.gmane.org>
Jakub Narebski <jnareb <at> gmail.com> writes:
> Perhaps gitweb should use user.name from the repository instead...
That would make more sense to me.
-- Pazu
^ permalink raw reply
* [PATCH] De-emphasise the symbolic link documentation.
From: Andy Parkins @ 2006-11-30 10:50 UTC (permalink / raw)
To: git
The fact that git has previously used symbolic links for representing
symbolic refs doesn't seem relevant to the current function of
git-symbolic-ref. This patch makes less of a big deal about the
symbolic link history and instead focuses on what git does now.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I've not been using git long enough to have ever experienced the symbolic-link
refs. It seems unnecessary that the man pages talk about something that doesn't
happen in such strong terms. (Was also slightly inaccurate, as it's not just
cygwin that uses symbolic refs)
Documentation/git-symbolic-ref.txt | 29 +++++++++++------------------
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt
index 68ac6a6..4bc35a1 100644
--- a/Documentation/git-symbolic-ref.txt
+++ b/Documentation/git-symbolic-ref.txt
@@ -19,29 +19,22 @@ argument to see on which branch your working tree is on.
Give two arguments, create or update a symbolic ref <name> to
point at the given branch <ref>.
-Traditionally, `.git/HEAD` is a symlink pointing at
-`refs/heads/master`. When we want to switch to another branch,
-we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we want
+A symbolic ref is a regular file that stores a string that
+begins with `ref: refs/`. For example, your `.git/HEAD` is
+a regular file whose contents is `ref: refs/heads/master`.
+
+NOTES
+-----
+In the past, `.git/HEAD` was a symbolic link pointing at
+`refs/heads/master`. When we wanted to switch to another branch,
+we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted
to find out which branch we are on, we did `readlink .git/HEAD`.
This was fine, and internally that is what still happens by
default, but on platforms that do not have working symlinks,
or that do not have the `readlink(1)` command, this was a bit
cumbersome. On some platforms, `ln -sf` does not even work as
-advertised (horrors).
-
-A symbolic ref can be a regular file that stores a string that
-begins with `ref: refs/`. For example, your `.git/HEAD` *can*
-be a regular file whose contents is `ref: refs/heads/master`.
-This can be used on a filesystem that does not support symbolic
-links. Instead of doing `readlink .git/HEAD`, `git-symbolic-ref
-HEAD` can be used to find out which branch we are on. To point
-the HEAD to `newbranch`, instead of `ln -sf refs/heads/newbranch
-.git/HEAD`, `git-symbolic-ref HEAD refs/heads/newbranch` can be
-used.
-
-Currently, .git/HEAD uses a regular file symbolic ref on Cygwin,
-and everywhere else it is implemented as a symlink. This can be
-changed at compilation time.
+advertised (horrors). Therefore symbolic links are now deprecated
+and symbolic refs are used by default.
Author
------
--
1.4.4.1
^ permalink raw reply related
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Andreas Ericsson @ 2006-11-30 11:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Junio C Hamano, Carl Worth, Nicolas Pitre,
git
In-Reply-To: <Pine.LNX.4.64.0611291859070.3513@woody.osdl.org>
Linus Torvalds wrote:
>
> That said, I have to admit that I usually (a) don't do this very often (ie
> this is not part of my daily routine) and (b) I tend to do "git reset"
> fairly soon afterwards (or alternatively, just "git commit -a") to get
> back to the situation where the index will match the current HEAD 100%
> again. So the "index doesn't match HEAD" situation is always just a
> _temporary_ thing for me.
>
A staging area is per definition meant to keep temporary things before
they are committed to their designated place so there's nothing odd
about that.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: git and bzr
From: Nguyen Thai Ngoc Duy @ 2006-11-30 11:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611301111310.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On 11/30/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> But here's an idea: tell the user that she has to tell git-commit which
> files she wants committed. Yes! That's it. Just tell it the friggin'
> files. And if you are a lazy bum, and want to commit _all_ modified
> files, git has a nice shortcut for ya: "-a".
It reminds me Microsoft Office Assistant :-) Let's make "git assistant
mode" that tries hard to guess user's desires and give them guidance.
Once they get used to git, they can disable that mode and back to
"plain git".
--
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-30 11:58 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0611300325r3a3fa8av141359c69d2377b5@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On 11/30/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> But here's an idea: tell the user that she has to tell git-commit which
>> files she wants committed. Yes! That's it. Just tell it the friggin'
>> files. And if you are a lazy bum, and want to commit _all_ modified
>> files, git has a nice shortcut for ya: "-a".
>
> It reminds me Microsoft Office Assistant :-) Let's make "git assistant
> mode" that tries hard to guess user's desires and give them guidance.
> Once they get used to git, they can disable that mode and back to
> "plain git".
The 'givor' (pun on Vi 'vigor') or 'gitor', or 'gator'.
$ git commit
[...]
nothing to commit
$ givor
$ git commit
Givor: You haven't marked any file for commit using "git-update-index <file>"
Givor: and you didn't provide files to commit with "git commit <file>"
Givor: so I assume that you wanted to commit all changed files
Givor: You can use "git commit -a" for that (-a is for --all)
;-)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-11-30 11:57 UTC (permalink / raw)
To: git; +Cc: Shawn Pearce
In-Reply-To: <200611281629.08636.andyparkins@gmail.com>
Andy Parkins wrote:
...
> Worse, if you allow that to happen, the supermodule can commit a state that
> cannot be retrieved from the submodule's repository. The ONLY thing a
> supermodule can record about a submodule is a commit.
So what? You have a submodule commit that only exists in the
supermodule. I fail to see the problem. The changes you made to the
submodule _in the supermodule_ can later be pulled from wherever you want.
Regards
Stephan
^ 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