* 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: [RFC] Submodules in GIT
From: Sven Verdoolaege @ 2006-11-30 16:33 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611301530.51171.andyparkins@gmail.com>
On Thu, Nov 30, 2006 at 03:30:49PM +0000, Andy Parkins wrote:
> On Thursday 2006 November 30 15:20, Sven Verdoolaege wrote:
> > How are you going to checkout the right commit of the lixcb repo if
> > you didn't store it in the supermodule ?
>
> Well, I know what the commit is /that/ was all that was stored. So I
Then I have no idea what you are talking about.
A commit _contains_ all the history that lead up to that commit,
so if you have the commit, then you also have the history.
^ permalink raw reply
* [PATCH 2/2] add a flag to disable using of Perls MakeMaker module.
From: Alex Riesen @ 2006-11-30 16:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
There installations (Cygwin + ActivateState Perl) where the generated makefiles
are not usable, because of lineendings and backslashes. The flags is
NO_PERL_MAKEMAKER.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Just remembered configure script. Maybe it could be taught to
notice the situation and do something about it (like setting the NO_MAKEMAKER).
[-- Attachment #2: 0002-add-a-flag-to-disable-using-of-Perls-MakeMaker-module.txt --]
[-- Type: text/plain, Size: 1736 bytes --]
From 06fc5e98754de98b44746d8962da16a58a5a5d28 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 30 Nov 2006 17:15:33 +0100
Subject: [PATCH] add a flag to disable using of Perls MakeMaker module.
There installations (Cygwin + ActivateState Perl) where the generated makefiles
are not usable, because of lineendings and backslashes. The flags is
NO_PERL_MAKEMAKER.
---
Makefile | 3 +++
perl/Makefile | 15 +++++++++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 5903a6f..3e6825b 100644
--- a/Makefile
+++ b/Makefile
@@ -539,6 +539,9 @@ endif
ifdef NO_ACCURATE_DIFF
BASIC_CFLAGS += -DNO_ACCURATE_DIFF
endif
+ifdef NO_PERL_MAKEMAKER
+ export NO_PERL_MAKEMAKER
+endif
# Shell quote (do not use $(call) to accommodate ancient setups);
diff --git a/perl/Makefile b/perl/Makefile
index cff24dd..a1b98bd 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -14,10 +14,25 @@ clean:
$(RM) ppport.h
$(RM) $(makfile)
+ifdef NO_PERL_MAKEMAKER
+instdir_SQ = $(subst ','\'',$(prefix)/lib)
+$(makfile): ../GIT-CFLAGS Makefile
+ echo all: > $@
+ echo ' :' >> $@
+ echo install: >> $@
+ echo ' mkdir -p $(instdir_SQ)' >> $@
+ echo ' $(RM) $(instdir_SQ)/Git.pm; cp Git.pm $(instdir_SQ)' >> $@
+ echo ' $(RM) $(instdir_SQ)/Error.pm; \
+ cp private-Error.pm $(instdir_SQ)/Error.pm' >> $@
+ echo instlibdir: >> $@
+ echo ' echo $(instdir_SQ)' >> $@
+else
$(makfile): Makefile.PL ../GIT-CFLAGS
'$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
+endif
# this is just added comfort for calling make directly in perl dir
# (even though GIT-CFLAGS aren't used yet. If ever)
../GIT-CFLAGS:
$(MAKE) -C .. GIT-CFLAGS
+
--
1.4.4.1.g3924-dirty
^ permalink raw reply related
* [PATCH 1/2] move Git.pm build instructions into perl/Makefile
From: Alex Riesen @ 2006-11-30 16:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20061121225911.GA24201@steel.home>
[-- Attachment #1: Type: text/plain, Size: 150 bytes --]
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
This is the first patch, just rebased upon current master.
The ActiveState-related parts follow
[-- Attachment #2: 0001-move-Git.pm-build-instructions-into-perl-Makefile.txt --]
[-- Type: text/plain, Size: 2986 bytes --]
From 95483f27aa0aede7d19b643f321994001ab1f065 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 21 Nov 2006 23:59:11 +0100
Subject: [PATCH] move Git.pm build instructions into perl/Makefile
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Makefile | 15 +++++++++------
perl/.gitignore | 3 ++-
perl/Makefile | 23 +++++++++++++++++++++++
3 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index de3e9f3..5903a6f 100644
--- a/Makefile
+++ b/Makefile
@@ -568,8 +568,8 @@ export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
-all: perl/Makefile
- $(MAKE) -C perl
+all:
+ $(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
$(MAKE) -C templates
strip: $(PROGRAMS) git$X
@@ -602,7 +602,11 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
chmod +x $@+
mv $@+ $@
-$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/Makefile
+$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
+
+perl/perl.mak: GIT-CFLAGS
+ $(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
+
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
rm -f $@ $@+
INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
@@ -796,7 +800,7 @@ install: all
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X gitk '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
- $(MAKE) -C perl install
+ $(MAKE) -C perl prefix='$(prefix_SQ)' install
if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
then \
ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
@@ -866,8 +870,7 @@ clean:
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
rm -f gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
- [ ! -f perl/Makefile ] || $(MAKE) -C perl/ clean || $(MAKE) -C perl/ clean
- rm -f perl/ppport.h perl/Makefile.old
+ $(MAKE) -C perl clean
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
rm -f GIT-VERSION-FILE GIT-CFLAGS
diff --git a/perl/.gitignore b/perl/.gitignore
index e990cae..98b2477 100644
--- a/perl/.gitignore
+++ b/perl/.gitignore
@@ -1,4 +1,5 @@
-Makefile
+perl.mak
+perl.mak.old
blib
blibdirs
pm_to_blib
diff --git a/perl/Makefile b/perl/Makefile
new file mode 100644
index 0000000..cff24dd
--- /dev/null
+++ b/perl/Makefile
@@ -0,0 +1,23 @@
+#
+# Makefile for perl support modules and routine
+#
+makfile:=perl.mak
+
+PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
+prefix_SQ = $(subst ','\'',$(prefix))
+
+all install instlibdir: $(makfile)
+ $(MAKE) -f $(makfile) $@
+
+clean:
+ test -f $(makfile) && $(MAKE) -f $(makfile) $@ || exit 0
+ $(RM) ppport.h
+ $(RM) $(makfile)
+
+$(makfile): Makefile.PL ../GIT-CFLAGS
+ '$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
+
+# this is just added comfort for calling make directly in perl dir
+# (even though GIT-CFLAGS aren't used yet. If ever)
+../GIT-CFLAGS:
+ $(MAKE) -C .. GIT-CFLAGS
--
1.4.4.1.g3924-dirty
^ permalink raw reply related
* Re: [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Jakub Narebski @ 2006-11-30 16:28 UTC (permalink / raw)
To: git
In-Reply-To: <200611301501.43436.andyparkins@gmail.com>
Andy Parkins wrote:
> Raimund Bauer offered this suggestion (paraphrased):
>
> "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?"
>
> Johannes Schindelin pointed out that this isn't the right thing to do for
> an --amend, so that is checked for. Additionally, it's probably not the
> right thing to do if any files are specified with "--only" or
> "--include", so they turn this behaviour off as well.
>
> Nguyen Thai Ngoc Duy asked that git-commit let you know it's done this
> by adding an extra comment to the commit message.
Insount on #git pointed out fragility of this solution with respect
to adding/removing/moving files, which dirties index (which might not be
understood by newbie user: "git commit" used to work, but doesn't work the
same when I added some files).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to prepend data when formatting patches ?
From: Francis Moreau @ 2006-11-30 16:19 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnx1wnk53ht.fsf@arm.com>
Hi
On 11/30/06, Catalin Marinas <catalin.marinas@arm.com> wrote:
> "Francis Moreau" <francis.moro@gmail.com> wrote:
> > I'd like to add to all patchs created by "git-format-patch" command
> > the following line:
> >
> > From: xxx.yyy <foo@crazy.com>
>
> In the headers or in the message body?
Johannes adviced me to use:
[format]
headers = "Organization: git-foo\n"
configuration. And it works both for mail header and message body.
thanks
--
^ permalink raw reply
* Re: How to prepend data when formatting patches ?
From: Francis Moreau @ 2006-11-30 16:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611301638430.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On 11/30/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 30 Nov 2006, Francis Moreau wrote:
>
> > I'd like to add to all patchs created by "git-format-patch" command
> > the following line:
> >
> > From: xxx.yyy <foo@crazy.com>
>
> From Documentation/git-format-patch.txt:
>
> -- snip --
>
> CONFIGURATION
> -------------
> You can specify extra mail header lines to be added to each
> message in the repository configuration as follows:
>
I stupily thought that it couldn't be used to prepend message for the
message body. But since it appends the line at the end of mail header,
it does the right thing for me.
Thanks for your quick answer
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-11-30 16:12 UTC (permalink / raw)
To: git
In-Reply-To: <456F0153.5000107@b-i-t.de>
sf wrote:
...
> A suffix : followed by a path, _followed by a suffix //::_ names the
> _revision_ at the given path in the tree-ish object named by the part
> before the colon.
Sorry, that was supposed to read: followed by a suffix //
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-11-30 16:08 UTC (permalink / raw)
To: git; +Cc: Andreas Ericsson
In-Reply-To: <456EFDDE.9010705@op5.se>
On Thursday 2006 November 30 15:50, Andreas Ericsson wrote:
> > 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 has? We're not talking supermodule specific things anymore, are we?
Not entirely, although I think it's going to be handy for submodules. It was
in a thread about remotes branches. By allowing checkout of any commit
rather than only those that have a ref/heads/ entry, you effectively have a
read-only checkout. You obviously couldn't commit to a repository like this,
because HEAD wouldn't point at anything that is changeable. It would be very
easy to just git-branch from there and start work though.
I think it's going to be necessary for the submodule work, because without it
the supermodule will have to create it's own temporary branches in the
submodule in order to checkout an arbitrary commit.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-11-30 16:05 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611301449.55171.andyparkins@gmail.com>
Andy Parkins wrote:
> On Thursday 2006 November 30 14:00, Stephan Feder wrote:
>
>> Again I do not see the problem. Probably I have a much simpler picture
>> of submodules: They are just commits in the supermodule's tree.
>> Everything else follows naturally from how git currently behaves.
>
> How are these commits any different from just having one big repository? If
> some of the development of the submodule is contained in the supermodule then
> it's not a submodule anymore.
Right now you only have commits of the top directory aka the super
project. Every subdirectory is just that: a directory (which git stores
as trees).
Now, if you have a subdirectory that git stores as a commit, not a tree,
you have a subproject. It is a directory with history, and because the
commit is part of your superprject, you have access to this history.
> Why bother with all the effort to make a separation between submodule and
> supermodule and then store the submodule commits in the supermodule. That's
> not supermodule/submodule git - that's just normal git.
No, it is not. Currently, there is no way to store a commit within the
contents of another commit. You can only store trees and blobs.
> Surely the whole point of having submodule's is so that you can take the
> submodule away. Let me give you an example. Let's say I have a project that
> uses the libxcb library (some random project out in the world that uses git).
> I've arranged it something like this:
>
> myproject (git root)
> |----- src
> |----- doc
> `----- libxcb (git root)
>
> This works fine; with one problem. When I make a commit in myproject, there
> is no link into the particular snapshot of the libxcb that I used at that
> moment. If libxcb moves on, and makes incompatible changes, then when I
> checkout an old version of myproject, it won't compile any more because I'll
> need to find out which commit of libxcb I used at the time.
OK.
> Submodules will solve this problem. In the future I'll be able to check out
> any commit of myproject and it will automatically checkout the right commit
> from the libxcb repository.
OK, I am still with you so far.
> Now let's say I'm working away and find a bug in
> libxcb; I fix it, commit it. That change had better be stored in the libxcb
> repository, and had better make no reference to the myproject repository. If
> it doesn't, I'm going to have to pollute the libxcb upstream repository with
> myproject if I want to share those fixes.
Here comes the part where we did not meet before.
Of course you do not make any reference from your subproject to your
superproject. You do exactly what you do in git today when you work with
different branches:
Step 1: You fix a bug in myproject's subdirectory libxcb.
Step 2: You commit to myproject. myproject now contains a new commit
object in path libxcb. (How to do that is up to the UI but at the
repository level the outcome should be obvious). This commit is local to
your repository.
Step 3: You propose your changes to the libxcb upstream (it might not be
a repository you have write access to). I use the following made up
syntax (see man git-rev-parse):
A suffix : followed by a path, _followed by a suffix //::_ names the
_revision_ at the given path in the tree-ish object named by the part
before the colon.
Step 3a: Generate a patch
git diff libxcb//^..libxcb//
Step 3b: Push your changes
git push <libxcb-repository> HEAD:libxcb//:<branch in libxcb-repository>
Step 3c: Let your changes be pulled
"Hello, please pull <myproject-repository> HEAD:libxcb//:<branch in
libxcb-repository>"
Step 4: Pull upstream version (hopefully with your changes, otherwise
you have to merge)
git pull <libxcb-repository> <branch in libxcb-repository>::HEAD:libxcb//
See, it works.
From what I understand you want to do the commit and push steps in one
go. How do you want to record local (to your superproject) changes to
the subproject?
Regards
^ permalink raw reply
* Re: v2.6.11 tag in kernel tree
From: Linus Torvalds @ 2006-11-30 16:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910611292002o289dc4d1u7bde2d457fa97d73@mail.gmail.com>
On Wed, 29 Nov 2006, Jon Smirl wrote:
>
> 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
Yes. We don't have that as a commit. The commit history starts with
v2.6.12-rc2.
> I'm trying to check out v2.6.11 so that I can figure out the changes a
> vendor made to it.
You can't check it out, since it's not a commit, but since it is a tree,
you can:
- use it as a base for "git diff"
git diff v2.6.11 <any-commit-goes-here>
- or if you want to use it as a base for development, create a new commit
and branch from it:
git-commit-tree v2.6.11 <<EOF
This is an initial commit starting at the state of Linux-v2.6.11
EOF
and then you can take the resulting SHA1 (that it wrote out to stdout),
and do
git checkout -b my-new-branch <sha1thatyoujustgot>
However, whatever you do, it won't be connected to the rest of the git
history.
Another possibility may be to get the historical Linux tree (which _does_
have a real v2.6.11, and that you _can_ graft together with the current
tree, and thus get full history), and then use that grafted whole-history
tree for whatever you want to do. That allows you to do things like
rebasing the end result (if you started a new branch based on 2.6.11) etc,
since it's now all connected.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Jakub Narebski @ 2006-11-30 16:05 UTC (permalink / raw)
To: git
In-Reply-To: <m2odqpm0d6.fsf@ziti.fhcrc.org>
Seth Falcon wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> By the way, I think that git-commit should also watch the return code
>> from the editor, so you can ^C it to abort git-commit --amend.
>
> For those using emacsclient, I don't think ^C will work. Is there
> another way to undo an amended commit? If not, is there any sense in
> detecting a magic comment to abort the ammend commit?
You can ^C the git-commit invocation.
And I guess ORIG_HEAD would help, and reflog certainly would help
reverting (undoing) amend of a commit.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Seth Falcon @ 2006-11-30 16:03 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0611300750t4adb4c97ibd65bc5b254e7efa@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 11/30/06, Seth Falcon <sethfalcon@gmail.com> wrote:
>>
>> For those using emacsclient, I don't think ^C will work. Is there
>> another way to undu an ammend commit? If not, is there any sense in
>> detecting a magic comment to abort the ammend commit?
>
> Uncomment to abort commit would be more intuitive.
^ permalink raw reply
* Re: How to prepend data when formatting patches ?
From: Catalin Marinas @ 2006-11-30 16:00 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <38b2ab8a0611300616j54a9f8ase9b4f1c305b7c22b@mail.gmail.com>
"Francis Moreau" <francis.moro@gmail.com> wrote:
> I'd like to add to all patchs created by "git-format-patch" command
> the following line:
>
> From: xxx.yyy <foo@crazy.com>
In the headers or in the message body? StGIT adds this line
automatically in the message body (and recently only if the sender is
different from the patch author but the templates are flexible and can
be changed).
--
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Linus Torvalds @ 2006-11-30 15:58 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Junio C Hamano, Carl Worth, Nicolas Pitre,
git
In-Reply-To: <456EBBE7.8030404@op5.se>
On Thu, 30 Nov 2006, Andreas Ericsson wrote:
> 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.
Sure. It's just that some people seem to expect the index to be different
from HEAD, and are afraid of being "confused" by it.
The fear seems to be about "git diff" getting different results from "git
diff HEAD", and always having to _check_ the two.
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.
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. For a very complicated merge, I could
possibly see somebody having a dirty index for a day or two and taking a
break with the index dirty, but
(a) I've certainly never seen that myself (and it would have to be
something very messy indeed - I remember multi-day merges with CVS,
but that was because CVS is so bad at merging, not because the merges
per se would have been all that messy)
(b) if you have a merge _that_ messy, I don't think you're likely to
forget about it, and rather than be confused about the difference
between 'git diff' and 'git diff HEAD', you'll be really really happy
that you have some way of seeing just the _remaining_ pieces, rather
than all the crud you already fixed up.
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.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-11-30 15:50 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611301530.51171.andyparkins@gmail.com>
Andy Parkins wrote:
> On Thursday 2006 November 30 15:20, Sven Verdoolaege wrote:
>
>> You can work on the submodule independently.
>
> It's not independent if any part of it is in the supermodule.
>
>>> some of the development of the submodule is contained in the supermodule
>>> then it's not a submodule anymore.
>> On the contrary, that's exactly what a submodule is supposed to be.
>
> I don't think so. I think it's just made some complicated normal repository.
>
I believe that Andy meant "development history" in his above scentence.
Naturally, using the code from the submodule while being capable of
developing the submodule separately from the supermodule is what
submodules are all about.
>> How are you going to checkout the right commit of the lixcb repo if
>> you didn't store it in the supermodule ?
>
> 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 has? We're not talking supermodule specific things anymore, are we?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nguyen Thai Ngoc Duy @ 2006-11-30 15:50 UTC (permalink / raw)
To: git
In-Reply-To: <m2odqpm0d6.fsf@ziti.fhcrc.org>
On 11/30/06, Seth Falcon <sethfalcon@gmail.com> wrote:
>
> For those using emacsclient, I don't think ^C will work. Is there
> another way to undu an ammend commit? If not, is there any sense in
> detecting a magic comment to abort the ammend commit?
Uncomment to abort commit would be more intuitive.
--
^ permalink raw reply
* Re: [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Salikh Zakirov @ 2006-11-30 15:43 UTC (permalink / raw)
To: git
In-Reply-To: <200611301501.43436.andyparkins@gmail.com>
Andy Parkins wrote:
> Raimund Bauer offered this suggestion (paraphrased):
>
> "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?"
Brilliant solution!
^ permalink raw reply
* Re: How to prepend data when formatting patches ?
From: Johannes Schindelin @ 2006-11-30 15:39 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <38b2ab8a0611300616j54a9f8ase9b4f1c305b7c22b@mail.gmail.com>
Hi,
On Thu, 30 Nov 2006, Francis Moreau wrote:
> I'd like to add to all patchs created by "git-format-patch" command
> the following line:
>
> From: xxx.yyy <foo@crazy.com>
From Documentation/git-format-patch.txt:
-- snip --
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each
message in the repository configuration as follows:
[format]
headers = "Organization: git-foo\n"
-- snap --
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Johannes Schindelin @ 2006-11-30 15:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekmlar$ask$2@sea.gmane.org>
Hi,
On Thu, 30 Nov 2006, Jakub Narebski wrote:
> Could we add suggestion by Andreas Ericsson to print in the "smart
> commit" case:
>
> Nothing to commit but changes in working tree. Assuming 'git commit -a'
>
> or something like that?
Only that you would not see it (or ignore it, as has been illustrated in
another thread), because your editor pops up, hiding that message.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-11-30 15:30 UTC (permalink / raw)
To: git
In-Reply-To: <20061130152011.GM12463MdfPADPa@greensroom.kotnet.org>
On Thursday 2006 November 30 15:20, Sven Verdoolaege wrote:
> You can work on the submodule independently.
It's not independent if any part of it is in the supermodule.
> > some of the development of the submodule is contained in the supermodule
> > then it's not a submodule anymore.
>
> On the contrary, that's exactly what a submodule is supposed to be.
I don't think so. I think it's just made some complicated normal repository.
> How are you going to checkout the right commit of the lixcb repo if
> you didn't store it in the supermodule ?
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.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Sven Verdoolaege @ 2006-11-30 15:20 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611301449.55171.andyparkins@gmail.com>
On Thu, Nov 30, 2006 at 02:49:53PM +0000, Andy Parkins wrote:
> How are these commits any different from just having one big repository? If
You can work on the submodule independently.
> some of the development of the submodule is contained in the supermodule then
> it's not a submodule anymore.
On the contrary, that's exactly what a submodule is supposed to be.
> Why bother with all the effort to make a separation between submodule and
> supermodule and then store the submodule commits in the supermodule. That's
> not supermodule/submodule git - that's just normal git.
[..]
> myproject (git root)
> |----- src
> |----- doc
> `----- libxcb (git root)
>
[..]
>
> Submodules will solve this problem. In the future I'll be able to check out
> any commit of myproject and it will automatically checkout the right commit
> from the libxcb repository.
How are you going to checkout the right commit of the lixcb repo if
you didn't store it in the supermodule ?
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Seth Falcon @ 2006-11-30 15:15 UTC (permalink / raw)
To: git
In-Reply-To: <ekmlf4$ask$3@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Salikh Zakirov wrote:
>
>> 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.
>
> By the way, I think that git-commit should also watch the return code
> from the editor, so you can ^C it to abort git-commit --amend.
For those using emacsclient, I don't think ^C will work. Is there
another way to undu an ammend commit? If not, is there any sense in
^ permalink raw reply
* [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Andy Parkins @ 2006-11-30 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0611300532x77c7fc8aq2ba77ff57b81cc05@mail.gmail.com>
Raimund Bauer offered this suggestion (paraphrased):
"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?"
Johannes Schindelin pointed out that this isn't the right thing to do for
an --amend, so that is checked for. Additionally, it's probably not the
right thing to do if any files are specified with "--only" or
"--include", so they turn this behaviour off as well.
Nguyen Thai Ngoc Duy asked that git-commit let you know it's done this
by adding an extra comment to the commit message.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
git-commit.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..b391257 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -265,6 +265,16 @@ $1"
done
case "$edit_flag" in t) no_edit= ;; esac
+# Clever commit - if this commit would do nothing, then make it an "all"
+# commit
+if [ -z "$(git-diff-index --cached --name-only HEAD)" \
+ -a -z "$amend" -a -z "$only" -a -z "$also" ]; then
+ echo "# There was nothing to commit but changes were detected in the" > $GIT_DIR/SQUASH_MSG
+ echo "# working tree. 'git commit -a' mode activated." >> $GIT_DIR/SQUASH_MSG
+ echo "#" >> $GIT_DIR/SQUASH_MSG
+ all=t
+fi
+
################################################################
# Sanity check options
--
1.4.4.1.g3ece-dirty
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-11-30 14:49 UTC (permalink / raw)
To: git
In-Reply-To: <456EE3F1.5070101@b-i-t.de>
On Thursday 2006 November 30 14:00, Stephan Feder wrote:
> Again I do not see the problem. Probably I have a much simpler picture
> of submodules: They are just commits in the supermodule's tree.
> Everything else follows naturally from how git currently behaves.
How are these commits any different from just having one big repository? If
some of the development of the submodule is contained in the supermodule then
it's not a submodule anymore.
Why bother with all the effort to make a separation between submodule and
supermodule and then store the submodule commits in the supermodule. That's
not supermodule/submodule git - that's just normal git.
Surely the whole point of having submodule's is so that you can take the
submodule away. Let me give you an example. Let's say I have a project that
uses the libxcb library (some random project out in the world that uses git).
I've arranged it something like this:
myproject (git root)
|----- src
|----- doc
`----- libxcb (git root)
This works fine; with one problem. When I make a commit in myproject, there
is no link into the particular snapshot of the libxcb that I used at that
moment. If libxcb moves on, and makes incompatible changes, then when I
checkout an old version of myproject, it won't compile any more because I'll
need to find out which commit of libxcb I used at the time.
Submodules will solve this problem. In the future I'll be able to check out
any commit of myproject and it will automatically checkout the right commit
from the libxcb repository. Now let's say I'm working away and find a bug in
libxcb; I fix it, commit it. That change had better be stored in the libxcb
repository, and had better make no reference to the myproject repository. If
it doesn't, I'm going to have to pollute the libxcb upstream repository with
myproject if I want to share those fixes.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ 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