* 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
* [PATCH] ls-files: Give hints when errors happen.
From: Andreas Ericsson @ 2006-11-30 11:28 UTC (permalink / raw)
To: git
Without this patch "git commit file.c file2.c" produces the not
so stellar output:
error: pathspec 'file.c' did not match any.
error: pathspec 'file2.c' did not match any.
With this patch, the output is changed to:
error: pathspec 'file.c' did not match any file(s) known to git.
error: pathspec 'file2.c' did not match any file(s) known to git.
Did you forget to 'git add'?
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
builtin-ls-files.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index ad8c41e..bc79ce4 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -487,10 +487,14 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
for (num = 0; pathspec[num]; num++) {
if (ps_matched[num])
continue;
- error("pathspec '%s' did not match any.",
+ error("pathspec '%s' did not match any file(s) known to git.",
pathspec[num] + prefix_offset);
errors++;
}
+
+ if (errors)
+ fprintf(stderr, "Did you forget to 'git add'?\n");
+
return errors ? 1 : 0;
}
--
1.4.4.1.GIT
^ permalink raw reply related
* [PATCH] git-diff: Introduce --index and deprecate --cached.
From: Andreas Ericsson @ 2006-11-30 11:43 UTC (permalink / raw)
To: git
'git diff --cached' still works, but its use is discouraged
in the documentation. 'git diff --index' does the same thing
and is consistent with how 'git apply --index' works.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Documentation/git-diff.txt | 6 ++++--
builtin-diff.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 228c4d9..3144864 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -22,8 +22,10 @@ the number of trees given to the command.
* When one <tree-ish> is given, the working tree and the named
tree are compared, using `git-diff-index`. The option
- `--cached` can be given to compare the index file and
+ `--index` can be given to compare the index file and
the named tree.
+ `--cached` is a deprecated alias for `--index`. It's use is
+ discouraged.
* When two <tree-ish>s are given, these two trees are compared
using `git-diff-tree`.
@@ -47,7 +49,7 @@ Various ways to check your working tree::
+
------------
$ git diff <1>
-$ git diff --cached <2>
+$ git diff --index <2>
$ git diff HEAD <3>
------------
+
diff --git a/builtin-diff.c b/builtin-diff.c
index a659020..1c535b1 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -137,7 +137,7 @@ static int builtin_diff_index(struct rev_info *revs,
int cached = 0;
while (1 < argc) {
const char *arg = argv[1];
- if (!strcmp(arg, "--cached"))
+ if (!strcmp(arg, "--index") || !strcmp(arg, "--cached"))
cached = 1;
else
usage(builtin_diff_usage);
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-11-30 12:16 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611292000.23778.andyparkins@gmail.com>
Andy Parkins wrote:
> On Wednesday 2006, November 29 16:03, Martin Waitz wrote:
>
>> - when updating the supermodule, you have to take care that your
>> submodules are on the right branch.
>> You might for example have some testing-throwawy branch in one
>> submodule and don't want to merge it with other changes yet.
>
> What is the "right" branch though? As I said above, if you're tracking one
> branch in the submodule then you've effectively locked that submodule to that
> branch for all supermodule uses. Or you've made yourself a big rod to beat
> yourself with everytime you want to do some development on an "off" branch on
> the submodule.
>
Perhaps I'm just daft, but I fail to see how you can safely track a
topic-branch that might get rewinded or rebased in the submodule without
crippling the supermodule. Wasn't the intention that the supermodule has
a new tree object (called "submodule") that points to a commit in the
submodule from where it gets its tree and stuff? Is the intention that
the supermodule pulls all of the submodules history into its own ODB? If
so, what's the difference between just having one large repository. If
not, how can you make it not break in case the commit it references in
the submodule is pruned away?
One possible way would ofcourse be to add something like this to the
supermodule commit:
submodule directory/commit-sha1
tree submodule-tree-sha1
but then you're in trouble because the supermodule will have the same
files as all the submodules stored in its own tree. I'm confused. Could
someone shed some light on how this sub-/super-module connection is
supposed to work in the supermodule's commit objects?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: git and bzr
From: Andreas Ericsson @ 2006-11-30 12:25 UTC (permalink / raw)
To: Marko Macek; +Cc: bazaar-ng, git
In-Reply-To: <456DD76C.4010902@gmx.net>
Marko Macek wrote:
> Linus Torvalds wrote:
>> 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.
>
> Actually, people (at least me) dislike the index because in the most common
> operations (status, diff, commit), they have to know that the command
> doesn't actually
> display all their work but just the 'indexed' part of it.
> For people used to cvs, svn and other systems it would be nicer if diff -a
> and commit -a (and possibly other commands) were the default.
>
Unless you do "git update-index" (and thus are already using the index)
on any files, "git diff" shows you exactly the changes between your last
commit and the working tree. There's nothing magic, odd or confusing
about it, no matter which scm you come from.
^ permalink raw reply
* Re: git and bzr
From: Johannes Schindelin @ 2006-11-30 12:23 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0611300325r3a3fa8av141359c69d2377b5@mail.gmail.com>
Hi,
On Thu, 30 Nov 2006, 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".
See git-gui from Shawn. It should really help new users with a graphical
user interface.
Ciao,
Dscho
^ permalink raw reply
* Re: git and bzr
From: Nicholas Allen @ 2006-11-30 12:36 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: bazaar-ng, git
In-Reply-To: <456B7C6A.80104@webdrake.net>
I also have a basic question about git regarding its content tracking
and merging.
Does this mean if I have, for example, a large C++ file with a bunch of
methods in it and I move one of the methods from the bottom of the file
to the top and in another branch someone makes a change to that method
that when I merge their changes git will merge their changes into the
method at the top of the file where I have moved it?
If so that would be really quite impressive!
Cheers,
Nick
Joseph Wakeling wrote:
> Hello all,
>
> Following the very interesting debate about the differences between bzr
> and git, I thought it was about time I tried to learn properly about git
> and how to use it. I've been using bzr for a good while now, although
> since I'm not a serious developer I only use it for simple purposes,
> keeping track of code I write on my own for academic projects.
>
> So, a few questions about differences I don't understand...
>
> First off a really dumb one: how do I identify myself to git, i.e. give
> it a name and email address? Currently it uses my system identity,
> My Name <username@computer.(none)>. I haven't found any equivalent of
> the bzr whoami command.
>
> Now to more serious business. One of the main operational differences I
> see as a new user is that bzr defaults to setting up branches in
> different locations, whereas git by default creates a repository where
> branches are different versions of the directory contents and switching
> branches *changes* the directory contents. bzr branch seems to be
> closer to git-clone than git-branch (N.B. I have never used bzr repos so
> might not be making a fair comparison).
>
> With this in mind, is there any significance to the "master" branch (is
> it intended e.g. to indicate a git repository's "stable" version
> according to the owner?), or is this just a convenient default name?
> Could I delete or rename it? Using bzr I would normally give the
> central branch(*) the name of the project.
>
> (* Central or main on my own system. Not intended to be central in the
> sense of a CVS-style version control setup:-)
>
> Any other useful comments that can be made to a bzr user about working
> with this difference, positive or negative aspects of it?
>
> Next question ... one of the reasons I started seriously thinking about
> git was that in the VCS comparison discussion, it was noted that git is
> a lot more flexible than bzr in terms of how it can track data (e.g. the
> git pickaxe command, although I understand that's not in the released
> version [1.4.4.1] yet?). A frustration with bzr is that pulling or
> merging patches from another branch or repo requires them to share the
> same HEAD. Is this a requirement in git or can I say, "Hey, I like that
> particular function in project XXX, I'm going to pull that individual
> bit of code and its development history into project YYY"?
>
> Last off (for now, I'm sure I'll think of more): is there any easy (or
> difficult) way to effectively import version history from a bzr
> repository, and vice versa?
>
> Thanks in advance for any comments,
>
> -- Joe
>
>
>
^ permalink raw reply
* Getting CVS and Git to play nicely in the same box
From: Alex Bennee @ 2006-11-30 12:39 UTC (permalink / raw)
To: Git Mailing List
Hi,
I'm trying to get a setup where I can use git for my day to day coding
on problems but still mirror a CVS repo. The situation is muddied
slightly by the way we manage changes in our CVS repository and
baselines.
The CVS manner of working means we create a branch at a given point to
do work on it:
BL1_CH2
/
/
BL1_CH1
BL1---/
And then in the meantime a new baseline may be released:
BL2 BL1_CH2
| /
| BL1_CH1
BL1--/
So we employ the "cvs -q update -dP -j BL1 -j BL2" on our development branch
BL2_CH2
/
BL2 BL1_CH2
| /
| BL1_CH1
BL1--/
I want to mirror this sort of behaviour it git (basically making the
cvs -j -j operation a git merge, separate from the normal development track).
I however also need to maintain the CVS meta-data so when I get to given points
I can commit my work into the main development server.
I can set up a git repo that ignore all the CVS gubbins with exclude info but the
CVS metadata gets in the way. I think I have to maintain two git repos, one that tracks the
baseline and one which is a clone (which can then pull updates) but has the CVS meta data
for my development branch. However CVS does seem to get very confused when the world moves
under it when you switch branches in GIT.
Has anyone successfully set up such a working environment? Can anyone offer any tips on how to
make it all work nicely?
--
Alex, homepage: http://www.bennee.com/~alex/
To iterate is human, to recurse, divine.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-11-30 12:40 UTC (permalink / raw)
To: git
In-Reply-To: <456ECBA5.7010409@op5.se>
On Thursday 2006 November 30 12:16, Andreas Ericsson wrote:
> > What is the "right" branch though? As I said above, if you're tracking
> > one branch in the submodule then you've effectively locked that submodule
> > to that branch for all supermodule uses. Or you've made yourself a big
> > rod to beat yourself with everytime you want to do some development on an
> > "off" branch on the submodule.
>
> Perhaps I'm just daft, but I fail to see how you can safely track a
> topic-branch that might get rewinded or rebased in the submodule without
> crippling the supermodule. Wasn't the intention that the supermodule has
Who said anything but rebase/rewind? As it happens though, I don't see why
you can't (it wouldn't be pleasant though). A rebase or rewind still leaves
the original commit in the object database, so provided no one runs
git-prune, there is no catastrophic failure.
> a new tree object (called "submodule") that points to a commit in the
> submodule from where it gets its tree and stuff? Is the intention that
> the supermodule pulls all of the submodules history into its own ODB? If
> so, what's the difference between just having one large repository. If
> not, how can you make it not break in case the commit it references in
> the submodule is pruned away?
I certainly never suggested anything /but/ storing a submodule type that
stores the commit. The current debate is about whether the supermodule
should track HEAD or some defined branch in the submodule.
> but then you're in trouble because the supermodule will have the same
> files as all the submodules stored in its own tree. I'm confused. Could
> someone shed some light on how this sub-/super-module connection is
> supposed to work in the supermodule's commit objects?
I don't really know, I only joined in to stand up against commit in the
supermodule triggering commits in the submodule. That lead to me trying to
get an understanding of how it would work.
As far as I can see, the only way a submodule is any use is if it is always a
submodule-commit-hash that is noted in the supermodule tree object. That
means that the supermodule will only commit clean submodules. The rest is
just UI to show something useful in the difficult cases when the submodule
tree is dirty.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: git and bzr
From: Nguyen Thai Ngoc Duy @ 2006-11-30 12:14 UTC (permalink / raw)
To: git
In-Reply-To: <ekmgud$oss$1@sea.gmane.org>
On 11/30/06, Jakub Narebski <jnareb@gmail.com> wrote:
> 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)
I am serious about that. I haven't thought of it as an independent
command/program though. Can you implement givor exactly like the above
example?
> ;-)
Okay now joke part. This command name is better :-D
$ git commit
[...]
nothing to commit
$ dammit
$ 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)
--
^ permalink raw reply
* Re: git and bzr
From: Andreas Ericsson @ 2006-11-30 12:45 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Carl Worth, git, bazaar-ng
In-Reply-To: <456E8147.9070304@gmx.net>
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?
Sounds sane. Especially if we couple it with a hint for the user to use
"commit -a" when he/she wants to do blanket commits.
So in essence that would mean:
If no pathspecs are given and index matches current HEAD, print out
"Nothing to commit but changes in working tree. Assuming 'git commit -a'
and then act accordingly. Carl, do you think that would satisfy the
desires of your RedHat peers? Always doing '-a' by default is terribly
wrong for those of us who actually use partial commits a lot, and it
would also rob git of a lot of its power.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: git and bzr
From: Johannes Schindelin @ 2006-11-30 12:47 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Joseph Wakeling, git, bazaar-ng
In-Reply-To: <456ED047.3030102@ableton.com>
Hi,
On Thu, 30 Nov 2006, Nicholas Allen wrote:
> Does this mean if I have, for example, a large C++ file with a bunch of
> methods in it and I move one of the methods from the bottom of the file
> to the top and in another branch someone makes a change to that method
> that when I merge their changes git will merge their changes into the
> method at the top of the file where I have moved it?
As for now, no, it does not. This is a shortcoming of RCS merge which does
the heavy-lifting.
Having said that, stay tuned for new developments: the functionality of
merge is being integrated in git. This opens the door to make use of the
code tracking support in git, to do exactly what you just proposed.
Ciao,
Dscho
^ permalink raw reply
* [PATCH/RFC] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Andy Parkins @ 2006-11-30 12:59 UTC (permalink / raw)
To: git
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.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I've been using this today, and so far it's been quite friendly. git-commit
is suddenly just doing the Right Thing.
It's so good that the only (small) hurdle, is remembering during an amend
that you need to update the index first to get any code changes in to the
amend - but that is the same as it ever was.
git-commit.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..e9aed2b 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -265,6 +265,13 @@ $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
+ all=t
+fi
+
################################################################
# Sanity check options
--
1.4.4.1.g3ece-dirty
^ permalink raw reply related
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Salikh Zakirov @ 2006-11-30 12:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5786opj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I've been playing with a "private edition" git to see how it
> feels like to use "git commit" that defaults to the "-a"
> behaviour, using myself as a guinea pig, for the rest of the
> evening.
Thanks a lot for the patches, Junio!
I am using them for two days, and my experience is great!
Many times it saved me annoyances of forgetting to put '-a' to 'git commit'.
It should be noted, that I mostly used 'git-commit files...'
or 'git-commit -a' forms before.
Someone said, that default '-a' does not go well with 'git-commit --amend',
and I second that. It was somewhat suprising to see that 'git commit --amend'
is going to include all of the dirty state into the commit,
and since there is no easy way to abort a --amend commit (because the comment
buffer wasn't empty, and :q! does not work as it would on the regular commit),
I had to untwine the changes manually.
^ permalink raw reply
* Re: Getting CVS and Git to play nicely in the same box
From: Jakub Narebski @ 2006-11-30 13:08 UTC (permalink / raw)
To: git
In-Reply-To: <1164890354.21950.92.camel@okra.transitives.com>
Alex Bennee wrote:
> Has anyone successfully set up such a working environment? Can anyone
> offer any tips on how to make it all work nicely?
Why not use git-cvsserver? Or port git-svn to CVS (or use Tailor)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Jakub Narebski @ 2006-11-30 13:16 UTC (permalink / raw)
To: git
In-Reply-To: <ekmkoe$a52$1@sea.gmane.org>
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.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Jakub Narebski @ 2006-11-30 13:13 UTC (permalink / raw)
To: git
In-Reply-To: <200611301259.32387.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.
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?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Andy Parkins @ 2006-11-30 13:24 UTC (permalink / raw)
To: git
In-Reply-To: <ekmlar$ask$2@sea.gmane.org>
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.
I've also output a message as suggested by Andreas Ericsson.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
git-commit.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..fabfeae 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -265,6 +265,14 @@ $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 "Nothing to commit but changes in working tree. Assuming 'git commit -a'"
+ all=t
+fi
+
################################################################
# Sanity check options
--
1.4.4.1.g3ece-dirty
^ permalink raw reply related
* Re: [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Nguyen Thai Ngoc Duy @ 2006-11-30 13:32 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611301324.04993.andyparkins@gmail.com>
> diff --git a/git-commit.sh b/git-commit.sh
> index 81c3a0c..fabfeae 100755
> --- a/git-commit.sh
> +++ b/git-commit.sh
> @@ -265,6 +265,14 @@ $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 "Nothing to commit but changes in working tree. Assuming 'git commit -a'"
This is hardly seen as the editor will immediately pop up. Better
pause a second or put it in commit template (I'd prefer the latter).
> + all=t
> +fi
> +
> ################################################################
> # Sanity check options
>
> --
> 1.4.4.1.g3ece-dirty
--
^ permalink raw reply
* Re: [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Jakub Narebski @ 2006-11-30 13:41 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0611300532x77c7fc8aq2ba77ff57b81cc05@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
>> +# 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 "Nothing to commit but changes in working tree. Assuming 'git commit -a'"
>
> This is hardly seen as the editor will immediately pop up. Better
> pause a second or put it in commit template (I'd prefer the latter).
Well, if it is VISUAL editor, you would see this. But adding this
to template is certainly good idea.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Getting CVS and Git to play nicely in the same box
From: Alex Bennee @ 2006-11-30 13:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekml1n$ask$1@sea.gmane.org>
On Thu, 2006-11-30 at 14:08 +0100, Jakub Narebski wrote:
> Alex Bennee wrote:
>
> > Has anyone successfully set up such a working environment? Can anyone
> > offer any tips on how to make it all work nicely?
>
> Why not use git-cvsserver? Or port git-svn to CVS (or use Tailor)?
I can't use git-cvsserver because the main repository is going to have
to stay on CVS for the time being. I don't think it could be used as a
drop in replacement for our existing server anyway as it doesn't support
tagging or branching.
Using git is my own personal indulgence (At least until I can
demonstrate it's worth while the other migrating ;-).
It looks like git-svn is the sort of tool I'd want for CVS although I'm
not sure how it would live with our CVS branched development model. I'll
have a poke around Tailor and see if that offers any help.
--
Alex, homepage: http://www.bennee.com/~alex/
Nobody wants constructive criticism. It's all we can do to put up with
constructive praise.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Stephan Feder @ 2006-11-30 14:00 UTC (permalink / raw)
To: Andy Parkins; +Cc: Shawn Pearce, git
In-Reply-To: <200611301255.41733.andyparkins@gmail.com>
Andy Parkins wrote:
> On Thursday 2006 November 30 11:57, sf 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.
>
> Eh? The files aren't stored in the supermodule, they're stored in the
> submodule. The ONLY thing in the supermodule is the commit hash. The
> objects for the submodule are still /in/ the submodule.
But you have got the submodule on your local disk anyway. So just setup
alternates and the supermodule contains all of the submodule.
> It sounds like you're suggesting that the supermodule commit includes files
> from the submodule? How can that work? The two aren't separate entities
> then, it's just one big repository.
It works as it always works in git: The supermodule commit contains the
submodule commit, the submodule commit contains the submodule files, so
the supermodule contains the submodule (at least the part of the
submodule that is visible). It _must_ be one repository but it need not
be big (once more, use alternates).
> I mean, what would this supermodule commit look like? Would it include a
> commit message? Which module should that commit message be about? Should
> the commit's parents be stored? Which parents, the submodule HEAD or the
> supermodule HEAD? Which tree object should it link to? The one in the
> submodule doesn't exist, so it'll have to be a freshly made up one for the
> supermodule - except now you've put submodule paths in the supermodule.
> Nope. That's never going to work.
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.
Of course it works. It is simple, it is the git way.
Am I missing the point?
Regards
Stephan
--
b.i.t.
beratungsgesellschaft für informations-technologie mbh
Stephan Feder
elisabethenstr. 62 fon: +49(0)6151/827575
64283 darmstadt fax: +49(0)6151/827576
mailto:sf@b-i-t.de www: http://www.b-i-t.de
^ permalink raw reply
* Re: Getting CVS and Git to play nicely in the same box
From: Jakub Narebski @ 2006-11-30 14:16 UTC (permalink / raw)
To: kernel-hacker; +Cc: git
In-Reply-To: <1164894847.21950.98.camel@okra.transitives.com>
Alex Bennee wrote:
> On Thu, 2006-11-30 at 14:08 +0100, Jakub Narebski wrote:
>> Alex Bennee wrote:
>>
>>> Has anyone successfully set up such a working environment? Can anyone
>>> offer any tips on how to make it all work nicely?
>>
>> Why not use git-cvsserver? Or port git-svn to CVS (or use Tailor)?
>
> I can't use git-cvsserver because the main repository is going to have
> to stay on CVS for the time being. I don't think it could be used as a
> drop in replacement for our existing server anyway as it doesn't support
> tagging or branching.
>
> Using git is my own personal indulgence (At least until I can
> demonstrate it's worth while the other migrating ;-).
Perhaps if not git-cvsserver, then git-cvsimport (or parsecvs, or cvs2git)
and git-exportcommit would be what you want.
> It looks like git-svn is the sort of tool I'd want for CVS although I'm
> not sure how it would live with our CVS branched development model. I'll
> have a poke around Tailor and see if that offers any help.
Well, Tailor used to work only with linear histories. But it is meant to
maintain parallel repositories in different formats.
--
Jakub Narebski
^ permalink raw reply
* How to prepend data when formatting patches ?
From: Francis Moreau @ 2006-11-30 14:16 UTC (permalink / raw)
To: git
Hi
I'd like to add to all patchs created by "git-format-patch" command
the following line:
From: xxx.yyy <foo@crazy.com>
I took a look to the command options and git's hooks but I don't find
a solution to this problem.
Is there any tricks to do this ?
thanks
--
^ permalink raw reply
* 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