* Re: Anyone running GIT on native Windows
From: A.S. Bradbury @ 2007-05-07 12:38 UTC (permalink / raw)
To: git
In-Reply-To: <463F14FF.F8DF11EB@eudaptics.com>
On 5/7/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> The next big thing to think about is an installer. Does anyone have a
> suggestion for a free installer tool? I only know about Microsoft's WiX
> (wix.sf.net), but it requires .NET (for the developer, not the user).
This is outside my normal realm of expertise, but I think NSIS
(http://nsis.sourceforge.net) is where it's at - notable users include
Firefox 2.0, OOo, VLC etc etc...
Alex
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Karl Hasselström @ 2007-05-07 12:30 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linus Torvalds, Junio C Hamano, Carl Worth, Michael Niedermayer,
Git Mailing List
In-Reply-To: <17983.6136.147062.346626@cargo.ozlabs.ibm.com>
On 2007-05-07 22:13:44 +1000, Paul Mackerras wrote:
> I have thought about rewriting it in a different language, but I
> haven't found anything that really appeals. I don't want to go to
> C/GTK or C/Qt since that would make it hard to port to Windows and
> MacOS AFAIK. Python/Tk would be a possibility, but I have never
> learnt python and I'm actually not all that comfortable with having
> to do things the object-oriented way.
>
> Any suggestions?
wxWidgets (http://www.wxwidgets.org/) is a cross-platform C++ library
that seems popular. There are bindings for lots of languages,
including Python (http://www.wxpython.org/).
"wxWidgets lets developers create applications for Win32, Mac OS X,
GTK+, X11, Motif, WinCE, and more using one codebase. It can be used
from languages such as C++, Python, Perl, and C#/.NET."
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Karl Hasselström @ 2007-05-07 12:16 UTC (permalink / raw)
To: Guilhem Bonnefille; +Cc: git
In-Reply-To: <8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com>
On 2007-05-07 13:40:33 +0200, Guilhem Bonnefille wrote:
> In order to improve my productivity with Git, and in order to avoid
> traps around moving from SVN to Git, I often use the Git Emacs mode.
> It is really usefull for beginners as it works similarly for CVS,
> SVN and Git: synthetic view of all modifications, easy selection of
> what will be commited... The biggest drawback of this "porcelain":
> using it, you do not understand the Git's index philosophy.
git-gui is a good tool here (so good, in fact, that this is the second
time today I spam the list about it). It shows very pedagogically the
diff between HEAD and index, and the diff between index and working
dir, and allows you to point and click your way to committing
precisely the subset of changes you intended to commit. As an added
bonus, it's perfectly usable even if you don't know anything about
emacs.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Paul Mackerras @ 2007-05-07 12:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Karl Hasselstr?m, Junio C Hamano, Carl Worth, Michael Niedermayer,
Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org>
Linus Torvalds writes:
> Finally, it realy _should_ check that the first 7 characters of the commit
> log (the ones it ignores by just asking for substring 7..) are actually
> the exact characters "commit ", but I'll blame my lack of comfort with the
> language again.
I have thought about rewriting it in a different language, but I
haven't found anything that really appeals. I don't want to go to
C/GTK or C/Qt since that would make it hard to port to Windows and
MacOS AFAIK. Python/Tk would be a possibility, but I have never
learnt python and I'm actually not all that comfortable with having to
do things the object-oriented way.
Any suggestions?
Tcl/Tk does come with a comprehensive set of man pages, usually
installed either in section n or sections 3tcl and 3tk. So you can do
"man string" to find out how to do string manipulations, for instance.
The syntax is quite regular and is explained in the "Tcl" man page.
Paul.
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Johannes Sixt @ 2007-05-07 12:01 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550705070448t7813d064mbac82abb45591888@mail.gmail.com>
Marco Costalba wrote:
>
> On 5/7/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> > Aaron Gray wrote:
> > > What I want is to be able to work in Windows CMD and envoke .sh scripts by
> > > association (unfortunately you have to add the .sh on the command name
> > > though).
> >
> > I run the mingw port exclusively from CMD without a .sh association. So
> > exclusively that I don't even know whether any other way of using the
> > tools even works. Of course, you have to get used to
> >
>
> Is it public available?
gitweb: http://repo.or.cz/w/git/mingw.git
clone: git://repo.or.cz/git/mingw.git
I only have either time to hack on mingw.git or a Windows installation,
but not both at the same time. Therefore, the port is now a bit falling
back (it's still at 1.5.1). I hope to be able to change this in a few
weeks.
The next big thing to think about is an installer. Does anyone have a
suggestion for a free installer tool? I only know about Microsoft's WiX
(wix.sf.net), but it requires .NET (for the developer, not the user).
-- Hannes
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Marco Costalba @ 2007-05-07 11:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <463ECEF4.625F3633@eudaptics.com>
On 5/7/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Aaron Gray wrote:
> > What I want is to be able to work in Windows CMD and envoke .sh scripts by
> > association (unfortunately you have to add the .sh on the command name
> > though).
>
> I run the mingw port exclusively from CMD without a .sh association. So
> exclusively that I don't even know whether any other way of using the
> tools even works. Of course, you have to get used to
>
Is it public available?
I see this as the long term solution to bring git under Windows
(Cygwin is just a temporary shortcut although very useful).
Why to port git under Windows?
Simply, to have better possibility to be chosen by the big projects under Linux!
See Mozilla-Firefox, as example, but not only, some of the biggest
projects under Linux are already ported or are being ported under
Windows (Apache, MySQL, OpenOffice, etc..) and in the future KDE.
Adopting a SCM that has a native porting under Windows is more and
more a sensible choice for the Linux big players.
The problem is that you don't chose an SCM each week, so when the
choice is made you have to wait years to have another opportunity (see
again Mozilla-Firefox thread on this subject), so not only git native
on Windows is the way to go, but also possibly quickly.
Marco
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Guilhem Bonnefille @ 2007-05-07 11:40 UTC (permalink / raw)
To: git
In-Reply-To: <vpqwszm9bm9.fsf@bauges.imag.fr>
Hi,
As a newbie, I'm agree with Matthieu: the Git's index is surprising
for people coming from CVS/SVN (mindless?) world. So a good
documentation about this, even in tutorials, is really important.
In order to improve my productivity with Git, and in order to avoid
traps around moving from SVN to Git, I often use the Git Emacs mode.
It is really usefull for beginners as it works similarly for CVS, SVN
and Git: synthetic view of all modifications, easy selection of what
will be commited... The biggest drawback of this "porcelain": using
it, you do not understand the Git's index philosophy.
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: Checkout fails when one branch contains a directory with the name of a file in the other branch
From: Tom Koelman @ 2007-05-07 11:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705071329170.4167@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 7 May 2007, Tom Koelman wrote:
>
>> I am not sure whether this is intentional or not. I am wondering why
>> this scenario fails, and if it is by design, how I should handle this
>> situation:
>>
>> [...]
>>
>> $ git checkout master
>> fatal: Untracked working tree file 'aFile' would be overwritten by merge.
>
> I tried to reproduce this behaviour, but it worked here. What Git version
> do you use? Mine says "git version 1.5.2.rc2.2435.ge5a9b".
>
> Hth,
> Dscho
I tried 1.5.1.3 under cygwin and 1.5.0.6 under Linux FC5.
Regards,
Tom Koelman
^ permalink raw reply
* Re: Checkout fails when one branch contains a directory with the name of a file in the other branch
From: Johannes Schindelin @ 2007-05-07 11:31 UTC (permalink / raw)
To: Tom Koelman; +Cc: git
In-Reply-To: <ubqgw51tf.fsf@assurancetourix.xs4all.nl>
Hi,
On Mon, 7 May 2007, Tom Koelman wrote:
> I am not sure whether this is intentional or not. I am wondering why
> this scenario fails, and if it is by design, how I should handle this
> situation:
>
> [...]
>
> $ git checkout master
> fatal: Untracked working tree file 'aFile' would be overwritten by merge.
I tried to reproduce this behaviour, but it worked here. What Git version
do you use? Mine says "git version 1.5.2.rc2.2435.ge5a9b".
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Document the fact that commit -a is the way to go for simple operations
From: Johannes Schindelin @ 2007-05-07 11:22 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqy7k1t56i.fsf@bauges.imag.fr>
Hi,
[BTW Matthieu, it seems you suffer the same problem as Jakub, since you do
not Cc the original authors in your replies.]
On Mon, 7 May 2007, Matthieu Moy wrote:
> My proposal is not perfect, and I'm sure we can do better.
>
> But the problem with most of git's manpages for beginners is that the
> documentation is mostly technical and factual. That is, it tells you
> what git will do if you provide such or such option, but not _why_ and
> _when_ you should use it.
>
> Probably just a "gitlink:" to the place in the user manual which talks
> about the index would be OK here.
NAK. You should not even consider reading the man pages before reading the
user manual. If you expect the man pages to give you a proper introduction
into _anything_ that is your problem, not the doc's.
We have such a lovely user manual, full of examples, a nice read, and it
even contains a section for the impatient. But the man pages are _meant_
to be technical. And I do not see a place in them for a back reference to
the user manual.
Ciao,
Dscho
^ permalink raw reply
* Checkout fails when one branch contains a directory with the name of a file in the other branch
From: Tom Koelman @ 2007-05-07 11:07 UTC (permalink / raw)
To: git
Hi,
I am not sure whether this is intentional or not. I am wondering why
this scenario fails, and if it is by design, how I should handle this
situation:
--------------------------------------------------------------------------------
$ mkdir test
$ cd test
$ git init
Initialized empty Git repository in .git/
$ echo aFile > aFile
$ git add aFile
$ git commit -m "initial"
Created initial commit a4aa48bb4ca57699341e380b17a1c3d92e44d08b
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 aFile
$ git checkout -b branch
Switched to a new branch "branch"
$ git rm aFile
rm 'aFile'
$ git commit -m "No aFile file anymore"
Created commit 6ac689ae4d7e8c0d82526d84563c12109b6cd900
1 files changed, 0 insertions(+), 1 deletions(-)
delete mode 100644 jacob
$ mkdir aFile
$ touch aFile/anotherFile
$ git add aFile/anotherFile
$ git commit -m "added aFile directory"
Created commit 634e5fff2fdb6365d4be5b2dca29e9c78164cb07
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 aFile/anotherFile
$ git checkout master
fatal: Untracked working tree file 'aFile' would be overwritten by merge.
--------------------------------------------------------------------------------
Regards,
Tom Koelman
^ permalink raw reply
* Re: "git reset --hard" not cleaning up working copy?
From: Johannes Schindelin @ 2007-05-07 11:13 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200705070951.39677.johan@herland.net>
Hi,
On Mon, 7 May 2007, Johan Herland wrote:
> When I "git reset --hard HEAD" to purge all my non-committed changes, it
> seems that files I created after the last commit (but not part of the
> index) are left lying around my working copy. Is this intended?
Bien sur it is intended! Git has no business deleting files it has not
been told about.
What you probably want is "git clean" after that reset...
Hth,
Dscho
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Johannes Schindelin @ 2007-05-07 11:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqd51duklo.fsf@bauges.imag.fr>
Hi,
On Mon, 7 May 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Just another reason to hate CVS. Because it trained people to do that. If
> > it was not for the training by CVS, I would have strongly opposed to the
> > introduction of the "-m" switch to commit. It _encourages_ bad commit
> > messages.
>
> Well, this really depends on the use-case, size of commit, ...
Okay, so I use "-m" myself sometimes.
> I often use a version control system for very low importance stuff. I
> don't want to type a 3-lines long message to describe a 2-lines long
> change in my ~/.emacs.el for example.
IIRC our record is 90+ lines of commit message for a one-line change.
> I also work with people using (sorry) svn to work collaboratively, but
> they don't even provide a log message: the version control system here
> is just a replacement for unison/NFS/whatever other way to have people
> edit files from different machines.
I positively _hate_ empty commit messages. There is _always_ something to
be said about the intent of the change, that has no place in the code.
> For sure, in a context where code quality and review is important, -m
> "xxx" isn't the way (except if you prefer your shell's line editor to
> your actual editor).
I also find it very useful for my own pleasure when reviewing some logs. I
track config files, small scripts, documents, etc. with Git, and I found
myself looking for something in _all_ of them. The commit messages helped.
Commit messages, BTW, are somewhat of an artform. You cannot imagine how
slow I am writing them, because they should be helpful not only for the
reviewer, but also for the casual git-blame user, who wants to find out
the rationale of a change.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/6] user-manual: stop deprecating the manual
From: Johannes Schindelin @ 2007-05-07 10:57 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <11785148472393-git-send-email->
Hi,
On Mon, 7 May 2007, J. Bruce Fields wrote:
> It's just as much a work-in-progress, but at least now it's gotten
> enough technical review to shake out most of the really bad lies, so
> hopefully it doesn't do any actual damage. And if we encourage people
> to read it, they'll be more likely to whine about it, which will help
> get it fixed faster.
FWIW I am a fan of the user manual. It is much, much better than the
tutorial/manpage combo, when you want to learn how to use Git.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-commit: fix usage to show (-F|-f) <logfile>.
From: Gerrit Pape @ 2007-05-07 10:54 UTC (permalink / raw)
To: git
In-Reply-To: <20070507105337.28685.qmail@895eb57f5f8cba.315fe32.mid.smarden.org>
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
git-commit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index e4518c4..bbd76c6 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
-USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i | -o] <path>...]'
+USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | (-F|-f) <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
--
1.5.1.2
^ permalink raw reply related
* [PATCH] Have git-revert, git-cherry-pick use $GIT_DIR/COMMIT_MSG instead of ./.msg.
From: Gerrit Pape @ 2007-05-07 10:53 UTC (permalink / raw)
To: git
In-Reply-To: <20070504143210.8690.qmail@a4171e0dbe98e3.315fe32.mid.smarden.org>
On Fri, May 04, 2007 at 05:28:21PM +0200, Alex Riesen wrote:
> On 5/4/07, Gerrit Pape <pape@smarden.org> wrote:
> >git-revert and git-cherry-pick left behind the commit message file ./.msg,
> >have them use the -f option to git-commit to properly cleanup the
> >automatically created file.
>
> Could we also have the files in $GIT_DIR instead of in working directory?
Yes, .git/COMMIT_MSG is already used by git-commit and git-svn, and can be
used here too.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
builtin-revert.c | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index 9acdf47..5aff283 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -126,14 +126,15 @@ char *get_encoding(const char *message)
return NULL;
}
-struct lock_file msg_file;
+static const char* msg_file;
+struct lock_file msg_file_lock;
static int msg_fd;
static void add_to_msg(const char *string)
{
int len = strlen(string);
if (write_in_full(msg_fd, string, len) < 0)
- die ("Could not write to .msg");
+ die ("Could not write to %s", msg_file);
}
static void add_message_to_msg(const char *message)
@@ -280,7 +281,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
* reverse of it if we are revert.
*/
- msg_fd = hold_lock_file_for_update(&msg_file, ".msg", 1);
+ msg_file = git_path("COMMIT_MSG");
+ msg_fd = hold_lock_file_for_update(&msg_file_lock, msg_file, 1);
encoding = get_encoding(message);
if (!encoding)
@@ -344,11 +346,11 @@ static int revert_or_cherry_pick(int argc, const char **argv)
i++;
}
}
- if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
- die ("Error wrapping up .msg");
+ if (close(msg_fd) || commit_lock_file(&msg_file_lock) < 0)
+ die ("Error wrapping up %s", msg_file);
unlink(target);
- if (rename(".msg", target))
- die ("Could not move .msg to %s", target);
+ if (rename(msg_file, target))
+ die ("Could not move %s to %s", msg_file, target);
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
"mark the corrected paths with 'git-add <paths>'\n"
@@ -361,8 +363,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
}
exit(1);
}
- if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
- die ("Error wrapping up .msg");
+ if (close(msg_fd) || commit_lock_file(&msg_file_lock) < 0)
+ die ("Error wrapping up %s", msg_file);
fprintf(stderr, "Finished one %s.\n", me);
/*
@@ -376,10 +378,10 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (!no_commit) {
if (edit)
- return execl_git_cmd("commit", "-n", "-f", ".msg",
+ return execl_git_cmd("commit", "-n", "-f", msg_file,
"-e", NULL);
else
- return execl_git_cmd("commit", "-n", "-f", ".msg",
+ return execl_git_cmd("commit", "-n", "-f", msg_file,
NULL);
}
if (reencoded_message)
--
1.5.1.2
^ permalink raw reply related
* Re: [PATCH] Document "commit --only".
From: Matthieu Moy @ 2007-05-07 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <vpq8xc1ujzq.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Nicolas Pitre <nico@cam.org> writes:
>
>> This looks really confusing. This is the default _only_ if files are
>> specified on the command line.
>>
>> IMHO I'd rather remove the option from the synopsis and flag it as
>> scheduled for removal in the source instead.
>
> I'm fine with this proposal. Next email will be a patch to do that
> (I'm not sure about the standard way to deprecate things in git, so I
> just added a warning when -o is used, feel free to improve it).
I messed up threading, sorry. Here's the patch again, but it's already
in a separate thead.
[PATCH] Remove mention of -o|--only in SYNOPSYS of git-commit.
This flag is actually useless since it is the default behavior, and
was mentionned in the SYNOPSYS, but not actually documented. Better
just deprecate it.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-commit.txt | 4 ++--
git-commit.sh | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 53a7bb0..4324ca0 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-commit' [-a | --interactive] [-s] [-v]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--no-verify] [-e] [--author <author>]
- [--] [[-i | -o ]<file>...]
+ [--] [[-i] <files>...]
DESCRIPTION
-----------
@@ -91,7 +91,7 @@ OPTIONS
Used to amend the tip of the current branch. Prepare the tree
object you would want to replace the latest commit as usual
- (this includes the usual -i/-o and explicit paths), and the
+ (this includes the usual -i and explicit paths), and the
commit log editor is seeded with the commit message from the
tip of the current branch. The commit you create replaces the
current tip -- if it was a merge, it will have the parents of
diff --git a/git-commit.sh b/git-commit.sh
index f28fc24..3913097 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
-USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i | -o] <path>...]'
+USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
@@ -138,6 +138,8 @@ do
shift
;;
-o|--o|--on|--onl|--only)
+ echo >&2 "Warning: --only option is now the default."
+ echo >&2 "It will be removed in a future version of git."
only=t
shift
;;
--
1.5.1.1
^ permalink raw reply related
* Re: [PATCH] submodule merge support
From: Johannes Sixt @ 2007-05-07 10:30 UTC (permalink / raw)
To: git
In-Reply-To: <20070507090346.GI30511@admingilde.org>
Martin Waitz wrote:
> On Sun, May 06, 2007 at 03:18:53PM -0700, Linus Torvalds wrote:
> > On Mon, 7 May 2007, Alex Riesen wrote:
> > > How about making all existing strategies just ignore submodules, and
> > > move recursive merge in the merge driver (git-merge.sh)?
> >
> > Yes, I think that's the right thing to do.
> >
> > I think it's the right thing for another reason: in a true "recursive"
> > merge, the submodules shouldn't be recursively merged anyway. *THEIR*
> > merge will have its own history, and doing it based on some random history
> > of the superproject is actually wrong anyway!
>
> Of course the submodule has to get its own history, it's not possible
> to do otherwise. But you have to trigger the submodule merge when you
> find a submodule-level conflict in the supermodule merge, just as
> you trigger file-level three-way merges, too.
I think you missed Linus's point: If the supermodule's merge leads to a
conflict in the submodule links, it is not appropriate to merge the
submodule.
Say you are merging commits A and B in the supermodule, and A uses v1.0
of the submodule and B uses v2.0 of submodule, then you can't just merge
v1.0 and v2.0 - instead, you have to make a decision whether the
supermodule's merge result is going to use v1.0 or v2.0 or even
something different like v2.1. An automatic merge cannot make this
decision for you (unless there was no conflict in the first place).
-- Hannes
^ permalink raw reply
* Re: [PATCH 4/6] user-manual: fix .gitconfig editing examples
From: Karl Hasselström @ 2007-05-07 9:42 UTC (permalink / raw)
To: Santi Béjar; +Cc: J. Bruce Fields, Junio C Hamano, git
In-Reply-To: <8aa486160705070233g4e9ed55cx747ab34426c9d369@mail.gmail.com>
On 2007-05-07 11:33:28 +0200, Santi Béjar wrote:
> On 5/7/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-05-07 09:29:23 +0200, Santi Béjar wrote:
> >
> > > I see it OK. Both in the mail and in the repo.
> >
> > The headers said, among other things,
> >
> > Content-Transfer-Encoding: QUOTED-PRINTABLE
> > Content-Type: TEXT/PLAIN; charset=ISO-8859-1
>
> My headers say:
>
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
Hmm. Someone's rewriting it, then. vger used to do that to my patches
for quite some time, until "stg mail" learned to write mails just
right.
Life would be so much simpler if e-mails just got sent from point A to
point B _without_ getting rewritten at every hop ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 4/6] user-manual: fix .gitconfig editing examples
From: Santi Béjar @ 2007-05-07 9:33 UTC (permalink / raw)
To: Karl Hasselström; +Cc: J. Bruce Fields, Junio C Hamano, git
In-Reply-To: <20070507092704.GA1106@diana.vm.bytemark.co.uk>
On 5/7/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-07 09:29:23 +0200, Santi Béjar wrote:
>
> > I see it OK. Both in the mail and in the repo.
>
> The headers said, among other things,
>
> Content-Transfer-Encoding: QUOTED-PRINTABLE
> Content-Type: TEXT/PLAIN; charset=ISO-8859-1
>
My headers say:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
> and the raw text of the body was
>
> Santi B=C3=A9jar points out that
>
> Note how the "é" in your name is encoded with two bytes.
>
> But if it's not broken in the repository, it's probably nothing to
> worry about. :-)
Or +1 for a git log that uses .mailcap in the commit message :-D
Santi
^ permalink raw reply
* Re: [PATCH 4/6] user-manual: fix .gitconfig editing examples
From: Karl Hasselström @ 2007-05-07 9:27 UTC (permalink / raw)
To: Santi Béjar; +Cc: J. Bruce Fields, Junio C Hamano, git
In-Reply-To: <8aa486160705070029l65a7b78cl33c50c4bc194f54b@mail.gmail.com>
On 2007-05-07 09:29:23 +0200, Santi Béjar wrote:
> I see it OK. Both in the mail and in the repo.
The headers said, among other things,
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
and the raw text of the body was
Santi B=C3=A9jar points out that
Note how the "é" in your name is encoded with two bytes.
But if it's not broken in the repository, it's probably nothing to
worry about. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] submodule merge support
From: Martin Waitz @ 2007-05-07 9:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.98.0705061517380.12945@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
hoi :)
On Sun, May 06, 2007 at 03:18:53PM -0700, Linus Torvalds wrote:
> On Mon, 7 May 2007, Alex Riesen wrote:
> > merge-recursive is a mess already, you just made even more so.
> > Besides, you completely forgot all other merge strategies.
> >
> > How about making all existing strategies just ignore submodules, and
> > move recursive merge in the merge driver (git-merge.sh)?
>
> Yes, I think that's the right thing to do.
>
> I think it's the right thing for another reason: in a true "recursive"
> merge, the submodules shouldn't be recursively merged anyway. *THEIR*
> merge will have its own history, and doing it based on some random history
> of the superproject is actually wrong anyway!
Of course the submodule has to get its own history, it's not possible
to do otherwise. But you have to trigger the submodule merge when you
find a submodule-level conflict in the supermodule merge, just as
you trigger file-level three-way merges, too.
This is really all which my patch does -- it starts a new instance of
the merge driver which only merges the submodule commit from the other
supermodule tree.
So it's not recursive in the merge-recursive way, but in a
call-git-merge-again way.
The comment about merge-recursive not being the best place is correct of
course.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 'upstream' branches.
From: David Woodhouse @ 2007-05-07 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vabwh8m5e.fsf@assigned-by-dhcp.cox.net>
On Sun, 2007-05-06 at 18:20 -0700, Junio C Hamano wrote:
> Of course not. Why are you even _PUBLISHING_ what your
> upstreams' origins are to begin with?
I have the master mtd-2.6.git tree on the server, of course.
I have a bunch of clones of that, on various computers I might be
sitting in front of. On each of those, I might pull from the upstream
tree (directly or indirectly) and push to my server. On each of those, I
might pull from my server and then set about pushing stuff to linus,
which starts with 'git-diff linus..' to vet it for sanity and 'git-log
linus..' to create a pull request.
I don't _care_ how commits from Linus' tree get into my tree. I just
want to know which is the latest commit in my tree that came from
upstream. How it got there is an implementation detail.
The other thing it's used for is excluding upstream commits from being
sent to the MTD commits list. Anything in the 'linus' branch won't get
sent. I _do_ have a fallback which also excludes any commits in the
local mirror of upstream -- but that mirror is pulled by git:// and only
daily, while my merges are usually from ssh://master.kernel.org/... so
when I merge and push to the server, the 'linus' branch may be many
commits ahead of the local mirror of upstream.
> By this, you are effectively getting the origin as seen by other
> people, and taking the most advanced one as the union of the
> origins.
>
> But step back and think about the reason why you would even want
> to know about the origin of each of your buddies
I don't. Except when I've pulled from them, and they've pulled from
Linus since I did. When I prepare for a merge to Linus, I don't _care_
about the last time _I_ pulled from upstream. I just care about the
latest commit which came from upstream, by whatever route.
Likewise, when I'm working on the OLPC git tree and I want to see what
we've got outstanding from Linus' tree.
> ... On the other hand, the earlier "diff" now needs to be written like
> this:
>
> $ git diff $(git merge-base linus A)..A
>
> Because this is the right thing to do in regular cases anyway,
> we even have a short-hand for that in the "three dot" form:
>
> $ git diff linus...A
>
> I think you already know these two things: "git-log linus..A is
> the right way to ask what A did relative to Linus, even when
> 'linus' is ahead of what A based his work on" and "the three-dot
> notation linus...A is the right thing to use when 'linus' could
> be ahead of what A is based on".
OK, that works for much of the local tracking stuff -- I wasn't
previously aware of the 'linus...A' notation.
So I can just 'git-fetch linus; git-log linus...' when preparing to
merge upstream, instead of trying to keep track of the merge-base across
many repositories. Thanks.
It doesn't solve the problem of what to exclude from the commits list.
But it does at least reduce the scope of the problem -- I only need to
handle that on my own trees, and it _will_ only ever go forward (because
I only ever do 'git-pull linus' in my clone of the mtd tree if it's
going to be immediately followed by 'git-push origin'.
--
dwmw2
^ permalink raw reply
* Re: 'upstream' branches.
From: Alex Riesen @ 2007-05-07 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Woodhouse, git, Linus Torvalds
In-Reply-To: <7vtzup6pzl.fsf@assigned-by-dhcp.cox.net>
On 5/7/07, Junio C Hamano <junkio@cox.net> wrote:
> >
> > Maybe we should not fail in the case the remote repo is older then
> > local, but just to try to fast-forward local reference after a fetch
> > and fail only if the fast-forward fails?
...
>
> Something like this untested patch should be sufficient if we
> want to go this route, but I am not convinced yet that this is
> the right thing to do. ...
Now, after I thought about that a bit more (and after your explanation
about David being silly), I think I was kind of silly as well.
The idea looks a bit dangerous (because of the local and remote
can divert from each other). If any, the reference mapping
syntax should clearly reveal that, more like
"TRY-FAST-FORWARD-MERGE ref1:ref2"
instead of that hideous minus. And come to think about that, I'd still
prefer to do that manually, as a real merge (I cannot know in advance
_when_ the repos divert, and which one of source repos will divert,
to entrust the operation an unattended process, and I have get-fetch
in cron files sometimes), so count me out as a user of that feature.
^ permalink raw reply
* [PATCH] Remove mention of -o|--only in SYNOPSYS of git-commit.
From: Matthieu Moy @ 2007-05-07 8:21 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
This flag is actually useless since it is the default behavior, and
was mentionned in the SYNOPSYS, but not actually documented. Better
just deprecate it.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-commit.txt | 4 ++--
git-commit.sh | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 53a7bb0..4324ca0 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-commit' [-a | --interactive] [-s] [-v]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--no-verify] [-e] [--author <author>]
- [--] [[-i | -o ]<file>...]
+ [--] [[-i] <files>...]
DESCRIPTION
-----------
@@ -91,7 +91,7 @@ OPTIONS
Used to amend the tip of the current branch. Prepare the tree
object you would want to replace the latest commit as usual
- (this includes the usual -i/-o and explicit paths), and the
+ (this includes the usual -i and explicit paths), and the
commit log editor is seeded with the commit message from the
tip of the current branch. The commit you create replaces the
current tip -- if it was a merge, it will have the parents of
diff --git a/git-commit.sh b/git-commit.sh
index f28fc24..3913097 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
-USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i | -o] <path>...]'
+USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
@@ -138,6 +138,8 @@ do
shift
;;
-o|--o|--on|--onl|--only)
+ echo >&2 "Warning: --only option is now the default."
+ echo >&2 "It will be removed in a future version of git."
only=t
shift
;;
--
1.5.1.1
^ permalink raw reply related
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