* Re: What's in git.git
From: Johannes Schindelin @ 2006-11-29 10:21 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, git
In-Reply-To: <87zmabv0i7.wl%cworth@cworth.org>
Hi,
On Tue, 28 Nov 2006, Carl Worth wrote:
> On Sat, 25 Nov 2006 02:12:38 -0800, Junio C Hamano wrote:
> > * The new "--depth $n" parameter to git clone/fetch tries to
> > limit the commit ancestry depth to $n.
> [...]
> Has though been given to make the depth selection consistent with
> other limiting options for rev-parse and rev-list? For example, I'd
> like to be able to use --since to get a shallow clone, (so should
> --depth instead be --max-count?, and can we re-use some existing
> machinery here?).
I briefly considered that, but decided against it, for two reasons: 1) it
puts the burden of calculation on the server, and 2) I was not at all sure
if the whole shallow stuff would be useful to begin with (and therefore
avoided complicated stuff as much as possible).
> > Petr Baudis (1):
> > Make git-clone --use-separate-remote the default
> ...
> > Junio C Hamano (19):
> > git-merge: make it usable as the first class UI
>
> Also very exciting. Please do keep up the user-interface improvements,
> everybody.
I concur.
Ciao,
Dscho
^ permalink raw reply
* Re: git and bzr
From: Johannes Schindelin @ 2006-11-29 10:49 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <456CBCD5.3050505@onlinehome.de>
Hi,
On Tue, 28 Nov 2006, Nicholas Allen wrote:
> [Linus wrote...]
> >
> > So the tools are certainly there. "git status" just isn't necessarily the
> > best one (or the best that it could be, for that matter)..
>
> I guess I hit a limitation in the output of status as opposed to a
> limitation in what git can do ;-)
I think it is something different altogether: you learnt how to use CVS,
and you learnt how to use bzr, and you are now biased towards using the
same names for the same operations in git.
I actually use git-status quite often, just before committing, to know
what I changed. But I will probable retrain my mind to use "git diff" or
even "git diff --stat", because it is more informative.
As for your scenario: There really should be a "what to do when my merge
screwed up?" document.
Ciao,
Dscho
^ permalink raw reply
* Re: git and bzr
From: Johannes Schindelin @ 2006-11-29 10:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0611281413310.4244@woody.osdl.org>
Hi,
On Tue, 28 Nov 2006, Linus Torvalds wrote:
> On Tue, 28 Nov 2006, Nicholas Allen wrote:
> >
> > All useful conflict status is lost isn't it?
>
> No, it's actually there, but "git status" doesn't really explain it to
> you.
>
> The go-to command tends to be "git diff", which after a merge will not
> show anything that already merged correctly (because it will have been
> updated in the git index _and_ updated in the working tree, so there will
> be no diff from stuff that auto-merged).
This is actually the most meaningful argument for not hiding the index.
Usually I explain it to people as a "staging area" standing between your
working directory, and the next committed state.
But I will start explaining the index with "what if your merge failed?".
Ciao,
Dscho
^ permalink raw reply
* Re: can I remove or move a tag in a remote repository?
From: Jim Meyering @ 2006-11-29 10:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0611291040590.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 28 Nov 2006, Junio C Hamano wrote:
...
>> I think this is due to overeager receive.denyNonFastForwards
>> configuration setting at the repository you are pushing into.
Junio, thank you for following up on this!
>> I _think_ what receive-pack does in this case is totally wrong.
>> It should either:
>>
>> (1) deny overwriting existing tags -- tags are meant to be
>> immutable so it should not allow them to be "updated"
>> regardless of fast-forwardness, or
>>
>> (2) allow overwriting things under refs/tags/ without any
>> fast-forward checking. After all, a tag could point at a
>> tree or a blob, and there is no fast-forwardness among
>> trees.
>>
>> The client side check in "git fetch" takes the latter viewpoint,
>> and I think we should be consistent with it.
>> Johannes, what do you think? Does the following patch look sane
>> to you?
>
> It does if you agree that (2) is correct.
>
> But I don't agree. cvs-head really should be a head IMHO, not a tag,
> because cvs-head really tracks a branch.
>
> I also think that git-fetch silently updating tags is wrong. Rather, it
> should warn that the tags are different. But I've been wrong before.
AFAIK, no one wants git-fetch to update tags _silently_.
I expected it give a diagnostic and fail by default -- and it already
does that. Pushing moved tags is serious business. I was hoping to be
able to use --force to override that fail-safe.
My goal is to maintain a symbolic reference "cvs-head" that points
to the newest git trunk node that's been mirrored to a CVS repository.
Without even considering any other option, I chose to use a lightweight
tag for that purpose, since I have a conceptual view that it's a label I
can move from one referent to another. It strikes me as counter-intuitive
to use a temporary git "branch" that way. Would that even work, removing
it and recreating it all the time? Hmm.. or maybe you mean to create the
branch once and then to merge from the trunk repeatedly. That seems
like unnecessary work, when all I want is a movable label.
I admit that I like the idea of release tags being immutable, but even
there, it's happened that I've made-but-not-published a release, then
realized that it wasn't quite complete. I was glad to be able to go
back and re-tag after making corrections.
I wouldn't mind having a way to specify that a pushed tag is *not*
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-29 11:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0611291145510.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Tue, 28 Nov 2006, Nicholas Allen wrote:
>
>> [Linus wrote...]
>>>
>>> So the tools are certainly there. "git status" just isn't necessarily the
>>> best one (or the best that it could be, for that matter)..
>>
>> I guess I hit a limitation in the output of status as opposed to a
>> limitation in what git can do ;-)
>
> I think it is something different altogether: you learnt how to use CVS,
> and you learnt how to use bzr, and you are now biased towards using the
> same names for the same operations in git.
>
> I actually use git-status quite often, just before committing, to know
> what I changed. But I will probable retrain my mind to use "git diff" or
> even "git diff --stat", because it is more informative.
>
> As for your scenario: There really should be a "what to do when my merge
> screwed up?" document.
It would be nice to have git-resolved (or git-resolve) wrapper around
git-update-index similar to git-add, git-mv, git-rm which would mark
file as resolved, without need for git-update-index, git-add and git-rm
even in the case of CONFLICT(rename/rename). Although I'm not sure
if it could work in all cases in the simple form of "git resolved <file>",
e.g. in the case of CONFLICT(add/add).
By the way, I wonder if git can detect the case when the same (or nearly
the same) file was added in two different branches under different
filename...
^ permalink raw reply
* [PATCH] hooks/pre-commit: add example to add Signed-off-by line to message
From: Johannes Schindelin @ 2006-11-29 11:20 UTC (permalink / raw)
To: Andy Parkins, git, junkio
It is good to have an example of how to supply a template for the
commit message anyway.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
templates/hooks--pre-commit | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 723a9ef..931f127 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -7,6 +7,13 @@
#
# To enable this hook, make this file executable.
+# Uncomment this to add a Signed-off-by line to the message.
+
+# . git-sh-setup
+# git var GIT_AUTHOR_IDENT | \
+# sed -n "s/^\(.*\) [0-9]\+ [-+][0-9]\+$/Signed-off-by: \1/p" \
+# > $GIT_DIR/SQUASH_MSG
+
# This is slightly modified from Andrew Morton's Perfect Patch.
# Lines you introduce should not have trailing whitespace.
# Also check for an indentation that has SP before a TAB.
--
1.4.4.1.gb475
^ permalink raw reply related
* Re: can I remove or move a tag in a remote repository?
From: Johannes Schindelin @ 2006-11-29 11:45 UTC (permalink / raw)
To: Jim Meyering; +Cc: Junio C Hamano, git
In-Reply-To: <87u00imsin.fsf@rho.meyering.net>
Hi,
On Wed, 29 Nov 2006, Jim Meyering wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I also think that git-fetch silently updating tags is wrong. Rather, it
> > should warn that the tags are different. But I've been wrong before.
>
> AFAIK, no one wants git-fetch to update tags _silently_. I expected it
> give a diagnostic and fail by default -- and it already does that.
Umm. I just tested it, and it said "updating tag" without failing.
> Pushing moved tags is serious business. I was hoping to be able to use
> --force to override that fail-safe.
Hmmm. Probably Junio's patch is correct after all, since tags are special
creatures: you do not expect them to change, but if, they can change
arbitrarily (as opposed to branches, which should evolve linearly).
> My goal is to maintain a symbolic reference "cvs-head" that points
> to the newest git trunk node that's been mirrored to a CVS repository.
But is that not just tracking another branch?
> Without even considering any other option, I chose to use a lightweight
> tag for that purpose, since I have a conceptual view that it's a label I
> can move from one referent to another. It strikes me as counter-intuitive
> to use a temporary git "branch" that way. Would that even work, removing
> it and recreating it all the time?
Yes, it would. Remember: a branch in git is just a named ref. It
literally used to be a 41-byte file pointing to the tip of the branch in
the ancestor graph. And you can update it with git-update-ref.
So, a branch in git is very much the movable label you are looking for.
Ciao,
Dscho
^ permalink raw reply
* Re: can I remove or move a tag in a remote repository?
From: Andy Whitcroft @ 2006-11-29 11:47 UTC (permalink / raw)
To: Jim Meyering; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <87u00imsin.fsf@rho.meyering.net>
Jim Meyering wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Tue, 28 Nov 2006, Junio C Hamano wrote:
> ...
>>> I think this is due to overeager receive.denyNonFastForwards
>>> configuration setting at the repository you are pushing into.
>
> Junio, thank you for following up on this!
>
>>> I _think_ what receive-pack does in this case is totally wrong.
>>> It should either:
>>>
>>> (1) deny overwriting existing tags -- tags are meant to be
>>> immutable so it should not allow them to be "updated"
>>> regardless of fast-forwardness, or
>>>
>>> (2) allow overwriting things under refs/tags/ without any
>>> fast-forward checking. After all, a tag could point at a
>>> tree or a blob, and there is no fast-forwardness among
>>> trees.
>>>
>>> The client side check in "git fetch" takes the latter viewpoint,
>>> and I think we should be consistent with it.
>
>>> Johannes, what do you think? Does the following patch look sane
>>> to you?
>> It does if you agree that (2) is correct.
>>
>> But I don't agree. cvs-head really should be a head IMHO, not a tag,
>> because cvs-head really tracks a branch.
>>
>> I also think that git-fetch silently updating tags is wrong. Rather, it
>> should warn that the tags are different. But I've been wrong before.
>
> AFAIK, no one wants git-fetch to update tags _silently_.
> I expected it give a diagnostic and fail by default -- and it already
> does that. Pushing moved tags is serious business. I was hoping to be
> able to use --force to override that fail-safe.
>
> My goal is to maintain a symbolic reference "cvs-head" that points
> to the newest git trunk node that's been mirrored to a CVS repository.
> Without even considering any other option, I chose to use a lightweight
> tag for that purpose, since I have a conceptual view that it's a label I
> can move from one referent to another. It strikes me as counter-intuitive
> to use a temporary git "branch" that way. Would that even work, removing
> it and recreating it all the time? Hmm.. or maybe you mean to create the
> branch once and then to merge from the trunk repeatedly. That seems
> like unnecessary work, when all I want is a movable label.
Well remember that all heads are simply references into the DAG, they
are all labels. 'heads' you are allowed to move and change, commit to
etc, but they are still just name -> sha1 mechanisms.
If the merge is a ff then there is no work. You could always use
'reset' instead to move the branch to the right place in the DAG.
>
> I admit that I like the idea of release tags being immutable, but even
> there, it's happened that I've made-but-not-published a release, then
> realized that it wasn't quite complete. I was glad to be able to go
> back and re-tag after making corrections.
>
> I wouldn't mind having a way to specify that a pushed tag is *not*
> immutable, with the default being it is immutable.
^ permalink raw reply
* git blame [was: git and bzr]
From: Joseph Wakeling @ 2006-11-29 12:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611281906520.3395@woody.osdl.org>
Linus Torvalds wrote:
> Now, with small changes, "git blame -C" will just ignore copies entirely,
Obvious when I think about it, otherwise every 'int i;' in the kernel
would have a huge blame list ... :-O
> I think Junio screwed up at some point. I'll send him a bug-report once
> I've triaged this a bit more, but I can recreate your breakage if I start
> a new git database and create two files in the root, and move data between
> them in the second commit (but if I instead create the second file in the
> second commit, and do the movement in the third commit, git blame -C works
> again ;).
Actually my setup was like the latter situation you describe, so blame
was probably working fine and just ignoring the small change. But
serendipity is a wonderful thing. :-)
-- Joe
^ permalink raw reply
* Re: [PATCH 2/3] git-svn: documentation updates
From: Pazu @ 2006-11-29 12:35 UTC (permalink / raw)
To: git
In-Reply-To: <20061129085419.GB4486@hand.yhbt.net>
Eric Wong <normalperson <at> yhbt.net> writes:
> Also, something that can wrap (git commit && git svn dcommit) into one
> step would be nice.
What I'd like to see is foreign systems integration for git pull/push. If git
had to use git-svn behind the curtains, so be it would be -very- nice if the
user could just use git pull/push.
-- Pazu
^ permalink raw reply
* Re: can I remove or move a tag in a remote repository?
From: Jakub Narebski @ 2006-11-29 13:46 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0611291220130.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>> Without even considering any other option, I chose to use a lightweight
>> tag for that purpose, since I have a conceptual view that it's a label I
>> can move from one referent to another. It strikes me as counter-intuitive
>> to use a temporary git "branch" that way. Would that even work, removing
>> it and recreating it all the time?
>
> Yes, it would. Remember: a branch in git is just a named ref. It
> literally used to be a 41-byte file pointing to the tip of the branch in
> the ancestor graph. And you can update it with git-update-ref.
>
> So, a branch in git is very much the movable label you are looking for.
And even if cvs-head does not fast-forward, remember that pu branch also
doesn't fast-forward (usually).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* git-merge-recursive-old?
From: Randal L. Schwartz @ 2006-11-29 14:57 UTC (permalink / raw)
To: git
I build daily, and apaprently I built git-merge-recursive-old,
but it's not in .gitignore. Needs to be added, no?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* gitk with arguments fails on OSX
From: Randal L. Schwartz @ 2006-11-29 15:04 UTC (permalink / raw)
To: git
Using the native "wish", gitk fails on OSX 10.4 if given any arguments.
For example, the failure for "gitk --all" is:
localhost.local:~/MIRROR/git-GIT % gitk --all
Error in startup script: unknown option "-state"
while executing
".bar.view entryconf 3 -state normal"
invoked from within
"if {$cmdline_files ne {} || $revtreeargs ne {}} {
# create a view for the files/dirs specified on the command line
set curview 1
set selec..."
(file "/opt/git/bin/gitk" line 6298)
What is -state ? What version of tk does it require?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: git-merge-recursive-old?
From: Johannes Schindelin @ 2006-11-29 15:07 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <868xhuxpun.fsf@blue.stonehenge.com>
Hi,
On Wed, 29 Nov 2006, Randal L. Schwartz wrote:
> I build daily, and apaprently I built git-merge-recursive-old,
> but it's not in .gitignore. Needs to be added, no?
To the contrary. You need to remove it: v1.4.4-g7cdbff1 removed it, but
you still have the generated file...
Hth,
Dscho
^ permalink raw reply
* Re: git-merge-recursive-old?
From: Randal L. Schwartz @ 2006-11-29 15:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611291606410.30004@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> Hi,
Johannes> On Wed, 29 Nov 2006, Randal L. Schwartz wrote:
>> I build daily, and apaprently I built git-merge-recursive-old,
>> but it's not in .gitignore. Needs to be added, no?
Johannes> To the contrary. You need to remove it: v1.4.4-g7cdbff1 removed it, but
Johannes> you still have the generated file...
yes, I see that now. It's too bad there's no mechanism for git to inform
trackers that this is not a mistake, but merely human action required. I
can't immediately think of any way to do it though.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: gitk with arguments fails on OSX
From: Johannes Schindelin @ 2006-11-29 15:10 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <864psixpj6.fsf@blue.stonehenge.com>
Hi,
On Wed, 29 Nov 2006, Randal L. Schwartz wrote:
>
> Using the native "wish", gitk fails on OSX 10.4 if given any arguments.
> For example, the failure for "gitk --all" is:
>
> localhost.local:~/MIRROR/git-GIT % gitk --all
> Error in startup script: unknown option "-state"
> while executing
Known problem:
http://thread.gmane.org/gmane.comp.version-control.git/31266/focus=31266
Hth,
Dscho
^ permalink raw reply
* Re: gitk with arguments fails on OSX
From: Randal L. Schwartz @ 2006-11-29 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611291609370.30004@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> Hi,
Johannes> On Wed, 29 Nov 2006, Randal L. Schwartz wrote:
>>
>> Using the native "wish", gitk fails on OSX 10.4 if given any arguments.
>> For example, the failure for "gitk --all" is:
>>
>> localhost.local:~/MIRROR/git-GIT % gitk --all
>> Error in startup script: unknown option "-state"
>> while executing
Johannes> Known problem:
Johannes> http://thread.gmane.org/gmane.comp.version-control.git/31266/focus=31266
The fix works for me. How about mainlining it?
From: Randal L. Schwartz <merlyn@localhost.local>
Date: Wed, 29 Nov 2006 07:20:04 -0800
Subject: [PATCH] patch from mailing list
---
gitk | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index ab383b3..d9df0a3 100755
--- a/gitk
+++ b/gitk
@@ -1632,8 +1632,8 @@ proc showview {n} {
set curview $n
set selectedview $n
- .bar.view entryconf 2 -state [expr {$n == 0? "disabled": "normal"}]
- .bar.view entryconf 3 -state [expr {$n == 0? "disabled": "normal"}]
+ .bar.view entryconf "Edit*" -state [expr {$n == 0? "disabled": "normal"}]
+ .bar.view entryconf "Delete*" -state [expr {$n == 0? "disabled": "normal"}]
if {![info exists viewdata($n)]} {
set pending_select $selid
@@ -6305,8 +6305,8 @@ if {$cmdline_files ne {} || $revtreeargs ne {}} {
set viewargs(1) $revtreeargs
set viewperm(1) 0
addviewmenu 1
- .bar.view entryconf 2 -state normal
- .bar.view entryconf 3 -state normal
+ .bar.view entryconf "Edit*" -state normal
+ .bar.view entryconf "Delete*" -state normal
}
if {[info exists permviews]} {
--
1.4.4.1.gf927
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply related
* Re: [PATCH 2/3] git-svn: documentation updates
From: Seth Falcon @ 2006-11-29 15:58 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061129085419.GB4486@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I've been considering something along those lines. I'm interested in
> renaming the current 'commit' command to something else (it still has
> its uses), but I haven't figured out what to call it...
I think this would be a sensible change and will help new users get
started with git-svn.
> Also, something that can wrap (git commit && git svn dcommit) into one
> step would be nice.
For my workflow, that wouldn't be all that useful. I find that I
accumulate a few commits locally and then send them all to svn. For
this workflow, what would be useful is if dcommit could understand a
command like:
git svn dcommit remotes/git-svn..HEAD~2
Sometimes I realize I should have sent a stack of commits to svn, but
now have some newer commits that aren't quite ready on the head of my
branch.
While the workaround is easy (create a new branch and dcommit from
it), I think there is a usability argument in that when one
sees an example like dcommit foo..bar, one expects all
the other magic to work. I feel for this and accidentally committed a
few commits I didn't want to send. If nothing else, perhaps git-svn
could error out and say, "hey, I don't do that".
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-11-29 16:03 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611281335.38728.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
hoi :)
On Tue, Nov 28, 2006 at 01:35:37PM +0000, Andy Parkins wrote:
> The reason I thought it would have to be HEAD at all times, is to prevent
> situations where the supermodule commit doesn't reflect the state of the
> current tree.
The way I wanted to address this is to show in the supermodule
git-status that the submodule is using another branch.
That way you are warned and can decide not to commit the supermodule.
I implemented tracking of refs/heads/master (not HEAD) without much
thinking, and only recently began to think about possible problems with
this approach.
But I think it is an important design decision to take, so I'd like to
have consensus here.
Pro HEAD:
- update-index on submodule really updates the supermodule index with
a commit that resembles the working directory.
Contra HEAD:
- HEAD is not garanteed to be equal to the working directory anyway,
you may have uncommitted changes.
- when updating the supermodule, you have to take care that your
submodules are on the right branch.
You might for example have some testing-throwawy branch in one
submodule and don't want to merge it with other changes yet.
Pro refs/heads/master:
- the supermodule really tracks one defined branch of development.
- you can easily overwrite one submodule by changing to another branch,
without fearing that changes in the supermodule change anything
there.
Contra refs/heads/master:
- after updating the supermodule, you may not have the correct working
directory checked out everywhere, because some submodules may be on a
different branch.
- there is one branch in the submodule which is special to all the other.
I think that most of the disadvantages of refs/heads/master can be
solved by printing the above-mentioned warning in git-status when the
submodule is using another branch (similiar to the
planned-but-not-implemented warn if the submodule has uncommited
changes).
I don't yet know how to cope with tracking HEAD directly, so I'm still
in favor of tracking refs/heads/master, as already implemented.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-svn and empty directories in svn (was: [PATCH 1.2/2 (fixed)] git-svn: fix output reporting from the delta fetcher)
From: Seth Falcon @ 2006-11-29 16:15 UTC (permalink / raw)
To: Eric Wong; +Cc: Pazu, git
In-Reply-To: <20061128201605.GA1369@localdomain>
Hi Eric, and list,
Eric Wong <normalperson@yhbt.net> writes:
> Seth Falcon <sethfalcon@gmail.com> wrote:
>> I think that presently git-svn does not create empty dirs when pulling
>> from svn. It would be nice to have such directories created since
>> some projects will expect the empty dir to be there (no need to track
>> it in git, IMO).
>
> Git itself cannot easily track empty directories (at least as far as
> update-index and checkout) goes.
>
> What I *can* do is run mktree and to force the creation of tree objects
> with a 4b825dc642cb6eb9a060e54bf8d69288fbee4904 (empty) sub tree and run
> commit-tree on it, but checkout/checkout-index would still need to be
> modified to support it.
>
> Is that something the git community wants?
I recently encountered a situation where code wasn't working for me
because git-svn didn't create an empty dir that is present in svn.
I'm not trying to argue for the sense/anti-sense of tracking empty
dirs in an scm, but I think this is an issue worth addressing in some
fashion. Here's why.
I think there are many potential git users out there who are currently
svn users. And git-svn is a really nice way to get started, but this
sort of stumbling block could really turn people off. For example, it
made me look pretty dumb when I carelessly complained to my colleague
about his code not working and then it turns out to be because my
super-advanced scm tool "messed things up".
One simple thing (I think it would be simple) is that git-svn could
issue a loud warning when it encounters an empty directory that it is
going to ignore.
I don't understand the implications adding the tracking of empty dirs
to git. I suspect it has been discussed before, but haven't yet gone
fishing in the list archives. I imagine it would make the argument
easier for folks wanting to switch a project from svn to git if this
wasn't one of the differences. For good or bad, I've often heard this
svn feature as a motivator to switch from cvs.
+ seth
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-11-29 16:15 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Shawn Pearce
In-Reply-To: <200611281629.08636.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]
hoi :)
On Tue, Nov 28, 2006 at 04:29:05PM +0000, Andy Parkins wrote:
> In summary, from the supermodule's point of view:
> * A submodule with changed working directory is "dirty-wd"
> * A submodule with changed index is "dirty-idx" from the supermodule's
> * A submodule with changed HEAD (since the last supermodule commit)
> is "changed but not updated" and can hence be "update-index"ed into the
> supermodule
> * A submodule with changed HEAD that has been added to the supermodule index
> is "updated but not checked in"
> * A submodule with changed HEAD (since the last supermodule update-index) is
> both "changed but not updated" _and_ "updated but not checked in", just
> like any normal file.
when tracking refs/heads/master instead of HEAD, you also get:
* A submodule where HEAD is not pointing to refs/heads/master is
"dirty-branch" or something.
> What's needed then:
> * A way of telling git to treat a particular directory as a submodule instead
> of a directory
This is handled by creating a GIT repository in this directory.
My current implementation needs some more magic by the user to add it to
the index, but I plan to change this to the way that GIT repositories
will be recognized as possible submodules.
> * git-status gets knowledge of how to check for "dirty" submodules
This is on top of my TODO.
> * git-commit-tree learns about how to store "submodule" object types in
> trees. The submodule object type will be nothing more than the hash of the
> current HEAD commit. (This might be my ignorance, perhaps it's just
> update-index that needs to know this)
it's only update-index that has to know this.
Otherwise it would be implicitly updated and you would never get your
"changed but not updated" status as above.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Don't require config file for "stg mail"
From: Catalin Marinas @ 2006-11-29 16:29 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20061129035930.6118.88435.stgit@dv.roinet.com>
On 29/11/06, Pavel Roskin <proski@gnu.org> wrote:
> When calculating the string to be used in the From: field, don't require
> it to come from the configuration file. Instead, reuse already known
> authname and authemail values as the default. They can be taken from
> the GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables.
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 reason I added a sender option is because the sender (that gets
added to the e-mail headers) may differ from the author of the patch.
I use one e-mail address as the author but I might be behind an SMTP
server which only allows a different e-mail address and therefore I
set the sender accordingly.
Once I merge Karl's patch, I'll modify StGIT to use the GIT defaults
if there is no sender configured.
--
^ permalink raw reply
* Re: git blame [was: git and bzr]
From: Linus Torvalds @ 2006-11-29 16:39 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: git
In-Reply-To: <456D7A76.3080605@webdrake.net>
On Wed, 29 Nov 2006, Joseph Wakeling wrote:
>
> Linus Torvalds wrote:
> > Now, with small changes, "git blame -C" will just ignore copies entirely,
>
> Obvious when I think about it, otherwise every 'int i;' in the kernel
> would have a huge blame list ... :-O
Indeed. We didn't do that heuristic originally, and the most common
sequence that was "blamed" on being copied from somewhere else was
something like the string
"<tab><tab><tab>}<nl><tab><tab>}<nl><tab>}<nl>"
which is obviously very common in C, especially when you have coding
conventions and people follow them ;)
> > them in the second commit (but if I instead create the second file in the
> > second commit, and do the movement in the third commit, git blame -C works
> > again ;).
>
> Actually my setup was like the latter situation you describe, so blame
> was probably working fine and just ignoring the small change. But
> serendipity is a wonderful thing. :-)
Yeah. As it turns out, the bug was really that "git blame" ended up just
not showing the filenames (that it had followed correctly), because it had
decided (incorrectly) that they weren't interesting because it all came
from the same commit, and it had already shown that commit (just not that
_file_ in that commit).
So it's fixed now, and probably would never trigger except for the stupid
special case that was "let's just show an example of this" ;)
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-29 17:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicholas Allen, Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0611291149440.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Wed, 29 Nov 2006, Johannes Schindelin wrote:
>
> On Tue, 28 Nov 2006, Linus Torvalds wrote:
> >
> > The go-to command tends to be "git diff", which after a merge will not
> > show anything that already merged correctly (because it will have been
> > updated in the git index _and_ updated in the working tree, so there will
> > be no diff from stuff that auto-merged).
>
> This is actually the most meaningful argument for not hiding the index.
> Usually I explain it to people as a "staging area" standing between your
> working directory, and the next committed state.
>
> But I will start explaining the index with "what if your merge failed?".
The thing is, the staging area is needed for a lot more than just merges.
Every single SCM has one, because even something as _trivial_ as "commit
all files" actually needs it. People don't just always think about it, and
the git staging area is "bigger" than most others.
Most other SCM's have a staging area that is just a list of filenames
(nobody thinks about it, but "commit everything" doesn't actually commit
everything at all - it just commits everything /in the list of files that
the SCM knows about/).
Git's staging area is just more complete than most other SCM's. It
contains not just the list of filenames, but their permissions too (where
a lot of other SCM's *cough*CVS*cough don't do permissions at all), but
also their content, and in the case of a merge conflict, the content of
the base version and the two branches to be merged.
So the index really _is_ required for pretty much all operations
(including very much "git commit -a", if only because of the filename
list), but yeah, if you start by talking about merge conflicts, maybe
people understand WHY it's also important to actually stage the _contents_
of a file too (multiple times, in fact, for a merge conflict), not just
its name.
So most of the time, when you use git, you can ignore the index. It's
really important, and it's used _all_ the time, but you can still mostly
ignore it. But when handling a merge conflict, the index is really what
sets git apart, and what really helps a LOT.
I've used other systems, but the git handling of merge conflicts really is
superior. Other SCM's think that the merge algorithm is interestign and
important, and that's bullshit. Merge algorithms are largely trivial and
uninteresting. The interestign and important thing is to just handle
failures well, and git does that _really_ well.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nicolas Pitre @ 2006-11-29 18:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7vr6vmsnly.fsf@assigned-by-dhcp.cox.net>
On Tue, 28 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > This argument has its converse. What you should _not_ have to worry
> > about all the time is whether your index really includes all the changes
> > you want included in your next commit.
>
> That's what we have "git diff" with various output options for;
> I often do "git diff --stat" or "git diff --name-status" when I
> know I am about to commit in a dirty working tree. I suspect
> that I am not getting your point.
I'm afraid this conversation is getting nowhere then.
> > And whether wanting to leave local changes in the working directory
> > without commiting them actually happen more often than wanting to commit
> > every changes is arguable.
>
> I do not think anybody is talking about which happens more
> often.
But I do.
> "screw the index" people do not have to worry about the
> index during the course of their changes in the working tree
> toward the next commit, and the only time they need to tell git
> (which _IS_ a system based on the index, dammit) about what they
> want to do with the index is at the commit time, and they tell
> git to "screw the index" by passing "-a" to "git commit".
No one talked about "screw the index" people. Those are happily using
Cogito.
We're talking about flattening the GIT learning curve. And as futile it
may seem to you that newbies should just use "commit -a" without
thinking, they still get bothered by that -a there. And probably
they'll forget about it once in a while and then GIT will _appear_ as
malfunctioning to them.
Of course amongst those newbies that didn't went away at this point
there will be those who decide to study further and come to the index
concept. And I hope that we all agree that the index is a powerful but
still advanced concept that should not be presented up front.
But my point is: why not making a very little change to the default
commit behavior. Really little change involving -a being the default.
The impact on newbies will be significant as they won't have to grok
everything at once to make sense of this -a we are telling them to use
blindly. And it will sort of match known expectations to commit
everything dirty.
And actually my point above is that in many cases, maybe the majoryty of
those case but this is arguable, what one is doing is not keeping dirty
and uncommited state around but rather committing every changes all the
time. In _that_ case, which might not be all the time but often enough,
then using -a is annoying[1].
So having -a the default makes GIT much more friendly to new users. You
"add" files, you "commit", you edit some files, you "commit" again, and
everything works fine, and you are happy and starts feeling good about
GIT.
Now for those who've seen the light and want to use the index it is not
much of a bother to add a -i to their commit invokation. At this point
if you understand the index you know what you're doing, and using -i
won't bother you as much it bothered you to use -a without knowing
why when you was a newbie.
But still, if you are a GIT old fart and have difficulties switching
habits, or if you simply are the kind with dirty not-to-commit state in
your tree and adding -i all the time bothers you just like [1] above,
then there is a way out! You are a GIT expert at this point of course
and certainly know how to add an alias for the -i to be implicit with
your "commit".
Therefore I think this is much more logical to ask the experts to add an
alias for "commit -i" than asking such tricks from less experienced
users. This is all my point is about.
^ 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