* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Eric Wong @ 2009-11-20 20:47 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git, Michael J Gruber
In-Reply-To: <20091119095307.GA30423@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Michael J Gruber <git@drmicha.warpmail.net> wrote:
> > I tried also with two svn sections to circumvent this:
> >
> > [svn-remote "svn"]
> > url = http://domain.com:/project/trunk
> > fetch = :refs/remotes/trunk
> > [svn-remote "svnr"]
> > url = http://domain.com:/project/releases
> > tags = /*:refs/remotes/tags/*
Hi Yaroslav,
Weird, I'm a bit confused by this myself but I'm out of time
at the moment, but swapping '[svn-remote "svn"]' and "[svn-remote "svnr"]"
seems to work, so there's apparently a bug in our handling of
svn-remote != "svn" somewhere...
So the following config should work:
[svn-remote "svnt"]
url = http://domain.com:/project/trunk
fetch = :refs/remotes/trunk
[svn-remote "svn"]
url = http://domain.com:/project/releases
tags = /*:refs/remotes/tags/*
You should probably run "git svn fetch -R svnt" before running
"git svn fetch" to pick up the tagged releases.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v3] gitk: add --no-replace-objects option
From: Christian Couder @ 2009-11-20 20:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <7vocmxvu7c.fsf@alter.siamese.dyndns.org>
On vendredi 20 novembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> > variable, and that is enough to make gitk ignore replace refs.
>
> This is a much less interesting implementation detail than everything
> else you should talk about the new feature you are adding; why is it the
> first sentence of the message?
This patch was previously the second patch in a 2 patch series so the
previous patch was already explaining some context. Perhaps I should have
sent the first patch again with this one.
> > The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
> > safer on some platforms, thanks to Johannes Sixt and Michael J
> > Gruber.
>
> And this is even less interesting.
>
> > Replace refs are useful to change some git objects after they
> > have started to be shared between different repositories. One
> > might want to ignore them to see the original state.
>
> This is what the reader needs to see to understand why this patch is
> worthy of consideration. It is a minor offense that the paragraph does
> not end with "... original state, and --no-replace-objects option can be
> used from the command line to do so", but this could be excused if this
> is made the first paragraph in the message, close to the subject.
Ok, I will send the full series again with these changes.
> I wonder if this switch deserves run-time flippability, though...
The following patch in master added run-time flippability to many commands:
http://git.kernel.org/?p=git/git.git;a=commit;h=b0fa7ab51b29d34579d8f6bb4443dfbcb8278c7a
and Michael J Gruber wrote "we need a way to specify
--no-replace-objects for gitk" in this message:
http://article.gmane.org/gmane.comp.version-control.git/132576/
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Junio C Hamano @ 2009-11-20 20:19 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1258732767-12741-3-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> We explain the user why uncommited changes can be problematic with merge,
> and point to "commit" and "stash" for the solution.
It is a shame that our existing documentation did not address this, and
the patch certainly takes us in the right direction.
I haven't seen a clear description of distinction between two vastly
different modes of failure from "git merge"---one that stops before even
touching anything, and one that results in conflicts to be resolved---and
how to tell them apart. As the course of action after these two modes are
quite different, it helps users to teach it early.
I attempted to summarize it some time ago:
http://gitster.livejournal.com/25801.html
(Completing a merge)
http://gitster.livejournal.com/29060.html
(Fun with keeping local changes around)
I am not very satisfied with them, but it might be a good start.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> Documentation/user-manual.txt | 14 +++++++++++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 269ec47..6b4a037 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1176,14 +1176,22 @@ How to merge
> ------------
>
> You can rejoin two diverging branches of development using
> -linkgit:git-merge[1]:
> +linkgit:git-merge[1].
>
> -------------------------------------------------
> $ git merge branchname
> -------------------------------------------------
>
> merges the development in the branch "branchname" into the current
> -branch. If there are conflicts--for example, if the same file is
> +branch. Note that Git merges committed changes, but not the working
> +tree itself. Therefore, if you have uncommitted changes touching the
> +same files as the ones impacted by the merge, Git will refuse to
> +proceed.
"but not the working tree itself" is not incorrect per-se, but misses the
point. How about...
A merge is made by combining the changes made in "branchname" and
the changes made up to the latest commit in your current branch
since their histories forke. The work tree is overwritten by the
result of the merge when this combining is done cleanly, or
overwritten by a half-merged results when this combining results
in conflicts. Therefore, ...
> +proceed. Most of the time, you will want to commit your changes before
> +you can merge, and if you don't, then linkgit:git-stash[1] can take
> +these changes away while you're doing the merge, and reapply them
> +afterwards.
> +
> +If there are conflicts--for example, if the same file is
> modified in two different ways in the remote branch and the local
> branch--then you are warned; the output may look something like this:
>
> @@ -1679,7 +1687,7 @@ Sharing development with others
> Getting updates with git pull
> -----------------------------
>
> -After you clone a repository and make a few changes of your own, you
> +After you clone a repository and commit a few changes of your own, you
> may wish to check the original repository for updates and merge them
> into your own work.
>
> --
> 1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Clemens Buchacher @ 2009-11-20 20:11 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, git, peff, jaysoffian, spearce
In-Reply-To: <905315640911201103w6d1da86duf41a53537672be8e@mail.gmail.com>
On Fri, Nov 20, 2009 at 11:03:13AM -0800, Tarmigan wrote:
> Here's a patch (cut-n-paste so it will probably be munged) for
> discussion of the port-fallback idea. If httpd cannot bind to 5541,
> it tries 15541 etc.
I would prefer if we skip the test right away. If we really want to try
different ports, we should first check that the port really is the problem.
Otherwise, the test will uselessly retry several times. Apache 2 writes
(98)Address already in use: make_sock: could not bind to address
127.0.0.1:5541
to stderr, which we could use to detect that error condition. But other web
servers are bound to behave differently.
Clemens
^ permalink raw reply
* Re: [PATCH v3] gitk: add --no-replace-objects option
From: Junio C Hamano @ 2009-11-20 20:04 UTC (permalink / raw)
To: Christian Couder
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091120194046.4469.53971.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> variable, and that is enough to make gitk ignore replace refs.
This is a much less interesting implementation detail than everything else
you should talk about the new feature you are adding; why is it the first
sentence of the message?
> The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
> safer on some platforms, thanks to Johannes Sixt and Michael J
> Gruber.
And this is even less interesting.
> Replace refs are useful to change some git objects after they
> have started to be shared between different repositories. One
> might want to ignore them to see the original state.
This is what the reader needs to see to understand why this patch is
worthy of consideration. It is a minor offense that the paragraph does
not end with "... original state, and --no-replace-objects option can be
used from the command line to do so", but this could be excused if this is
made the first paragraph in the message, close to the subject.
I wonder if this switch deserves run-time flippability, though...
> Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> gitk-git/gitk | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index a0214b7..c586b93 100644
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -128,7 +128,7 @@ proc unmerged_files {files} {
> }
>
> proc parseviewargs {n arglist} {
> - global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs
> + global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
>
> set vdatemode($n) 0
> set vmergeonly($n) 0
> @@ -208,6 +208,9 @@ proc parseviewargs {n arglist} {
> # git rev-parse doesn't understand --merge
> lappend revargs --gitk-symmetric-diff-marker MERGE_HEAD...HEAD
> }
> + "--no-replace-objects" {
> + set env(GIT_NO_REPLACE_OBJECTS) "1"
> + }
> "-*" {
> # Other flag arguments including -<n>
> if {[string is digit -strict [string range $arg 1 end]]} {
> --
> 1.6.5.1.gaf97d
^ permalink raw reply
* [PATCH v3] gitk: add --no-replace-objects option
From: Christian Couder @ 2009-11-20 19:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
This option simply sets the GIT_NO_REPLACE_OBJECTS environment
variable, and that is enough to make gitk ignore replace refs.
The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
safer on some platforms, thanks to Johannes Sixt and Michael J
Gruber.
Replace refs are useful to change some git objects after they
have started to be shared between different repositories. One
might want to ignore them to see the original state.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
gitk-git/gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..c586b93 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -128,7 +128,7 @@ proc unmerged_files {files} {
}
proc parseviewargs {n arglist} {
- global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs
+ global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -208,6 +208,9 @@ proc parseviewargs {n arglist} {
# git rev-parse doesn't understand --merge
lappend revargs --gitk-symmetric-diff-marker MERGE_HEAD...HEAD
}
+ "--no-replace-objects" {
+ set env(GIT_NO_REPLACE_OBJECTS) "1"
+ }
"-*" {
# Other flag arguments including -<n>
if {[string is digit -strict [string range $arg 1 end]]} {
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Ben Walton @ 2009-11-20 19:31 UTC (permalink / raw)
To: Derek, git
In-Reply-To: <1258744985-sup-932@ntdws12.chass.utoronto.ca>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Excerpts from Ben Walton's message of Fri Nov 20 14:26:41 -0500 2009:
> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/git/trunk/Makefile
> [1] Basic docs, etc: http://sourceforge.net/apps/trac/gar/
Using svn is really painful, btw. I didn't think of the irony of
these links when hitting send.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Ben Walton @ 2009-11-20 19:26 UTC (permalink / raw)
To: Derek; +Cc: git
In-Reply-To: <loom.20091120T201341-834@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
Excerpts from Derek's message of Fri Nov 20 14:15:40 -0500 2009:
> Unfortunately I need 1.5.4.2 version specifically as I want it to work with
> gibak - http://eigenclass.org/hiki/gibak-backup-system-introduction
Ok, I can't help then. We have archival versions of older git
packages, but the first version I published was 1.6.0.5.
If you're willing to install the dependency packages, you could build
your own version using the recipe stored in our GAR[1] repository:
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/git/trunk/Makefile
May help, may not.
-Ben
[1] Basic docs, etc: http://sourceforge.net/apps/trac/gar/
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Derek @ 2009-11-20 19:15 UTC (permalink / raw)
To: git
In-Reply-To: <1258743998-sup-86@ntdws12.chass.utoronto.ca>
Ben Walton <bwalton <at> artsci.utoronto.ca> writes:
> If you don't need that version specifically, have a look at:
>
> http://opencsw.org/packages/git
>
> It might save you some time.
>
> HTH.
> -Ben
>
Unfortunately I need 1.5.4.2 version specifically as I want it to work with
gibak - http://eigenclass.org/hiki/gibak-backup-system-introduction
^ permalink raw reply
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Ben Walton @ 2009-11-20 19:07 UTC (permalink / raw)
To: Derek; +Cc: git
In-Reply-To: <loom.20091120T194807-826@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Excerpts from Derek's message of Fri Nov 20 13:50:13 -0500 2009:
> Any ideas?
If you don't need that version specifically, have a look at:
http://opencsw.org/packages/git
It might save you some time.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Tarmigan @ 2009-11-20 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff, jaysoffian, drizzd, spearce
In-Reply-To: <7vd43d7hdo.fsf@alter.siamese.dyndns.org>
On Fri, Nov 20, 2009 at 12:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan <tarmigan+git@gmail.com> writes:
>
>> With smart http, git over http is likely to become much more common.
>> To increase testing of smart http, enable the http tests by default.
>
> Sorry, but no test that listens to network ports should be enabled by
> default; otherwise it will break automated, unattended tests people have
> already set up randomly, depending on when the port happens to be
> available for use by the tests.
Is this the only concern or are there security or other issues as well?
If that is the only concern, we could have the tests automatically
fall back to listening on a different port. Even if we didn't, if
httpd cannot startup because it can't bind to the port, the http tests
say
* skipping test, web server setup failed
and exit with test_done before any of the tests actually fail.
Here's a patch (cut-n-paste so it will probably be munged) for
discussion of the port-fallback idea. If httpd cannot bind to 5541,
it tries 15541 etc. You can test this by running "nc -l 5541 &"
before the test. If this approach might be acceptable, I can send a
properly formatted patch.
Comments?
Thanks,
Tarmigan
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index 797a2d6..a8eb6fa 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -77,7 +77,7 @@ prepare_httpd() {
if test -n "$LIB_HTTPD_SSL"
then
- HTTPD_URL=https://127.0.0.1:$LIB_HTTPD_PORT
+ HTTPD_URL=https://127.0.0.1
RANDFILE_PATH="$HTTPD_ROOT_PATH"/.rnd openssl req \
-config "$TEST_PATH/ssl.cnf" \
@@ -88,7 +88,7 @@ prepare_httpd() {
export GIT_SSL_NO_VERIFY
HTTPD_PARA="$HTTPD_PARA -DSSL"
else
- HTTPD_URL=http://127.0.0.1:$LIB_HTTPD_PORT
+ HTTPD_URL=http://127.0.0.1
fi
if test -n "$LIB_HTTPD_DAV" -o -n "$LIB_HTTPD_SVN"
@@ -109,16 +109,29 @@ start_httpd() {
trap 'code=$?; stop_httpd; (exit $code); die' EXIT
- "$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
- -f "$TEST_PATH/apache.conf" $HTTPD_PARA \
- -c "Listen 127.0.0.1:$LIB_HTTPD_PORT" -k start \
- >&3 2>&4
- if test $? -ne 0
- then
- say "skipping test, web server setup failed"
- trap 'die' EXIT
- test_done
- fi
+ while true
+ do
+ "$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
+ -f "$TEST_PATH/apache.conf" $HTTPD_PARA \
+ -c "Listen 127.0.0.1:$LIB_HTTPD_PORT" -k start \
+ >&3 2>&4
+ if test $? -ne 0
+ then
+ if test $LIB_HTTPD_PORT -gt 40000
+ then
+ say "skipping test, web server setup failed"
+ trap 'die' EXIT
+ test_done
+ fi
+ LIB_HTTPD_PORT=$(($LIB_HTTPD_PORT + 10000))
+ say "trying port $LIB_HTTPD_PORT"
+ continue
+ else
+ break
+ fi
+ done
+
+ HTTPD_URL="$HTTPD_URL:$LIB_HTTPD_PORT"
}
stop_httpd() {
^ permalink raw reply related
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: David Aguilar @ 2009-11-20 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, peff, sam, git
In-Reply-To: <7vhbsp7htq.fsf@alter.siamese.dyndns.org>
On Thu, Nov 19, 2009 at 11:53:37PM -0800, Junio C Hamano wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > I have no problem with using git difftool if the underlying git is new
> > enough, I just don't want gitk to explode when it isn't.
>
> I somehow doubt there are many users who use pre 1.6.3 git but keep their
> gitk separately updated to very recent version, so personally I wouldn't
> worry too much about this.
>
> > Also, I don't think we should remove the ability for the user to
> > choose which external diff tool to use.
>
> This is a larger concern. Does "difftool" allow use of an arbitrary tool
> like how gitk does (I have a suspicion that it is not as flexible)?
difftool supports arbitrary tools through configuration.
For arbitrary tools we set difftool.$name.cmd and
diff.tool = $name.
If gitk were to have a difftool paradigm then it might
be nice to have a text field mapped to the diff.tool variable.
The patch didn't address the diff.tool configuration variable
so that's a concern if we are to pursue difftool further.
The argument in favor of difftool is one of user
expectations. From a user's POV it ~seems~ desirable for
gitk to honor difftool configurations. The easiest way for
gitk to do that is to use git-difftool and not worry about
the details of how arbitrary tools are setup.
Later work could be done to provide UI for setting up
arbitrary tools inside of gitk. My gut feeling
is that gitk isn't a git config editor.
This is why the difftool patch took the minimalist approach.
It trusts the user to have things configured to their
liking and trusts git-difftool to do the right thing
when no such configuration exists.
I think it's a question of whether this is something we'd
want to change. It certainly doesn't bother me either way.
I might be the only person who'd notice such small details
so my vote-in-code is with my v2 $TMPDIR patch until someone
else thinks that using difftool inside of gitk is a good idea.
At which point I would probably pursue it with the minimalist
approach first and then gradually add UI for the pertinent
git config variables.
Just my .02,
--
David
^ permalink raw reply
* GIT 1.5.4.2 installation on Solaris 8 problems
From: Derek @ 2009-11-20 18:50 UTC (permalink / raw)
To: git
I get the following error after make install:
install: git-fetch-pack was not found anywhere!
make: *** [install] Error 2
Any ideas?
^ permalink raw reply
* Re: [PATCH] let core.excludesfile default to ~/.gitignore.
From: David Aguilar @ 2009-11-20 18:50 UTC (permalink / raw)
To: Stefan Naewe; +Cc: Matthieu Moy, git@vger.kernel.org, gitster@pobox.com
In-Reply-To: <4B06A7EE.2090801@atlas-elektronik.com>
On Fri, Nov 20, 2009 at 03:30:06PM +0100, Stefan Naewe wrote:
> On 11/20/2009 2:23 PM, Matthieu Moy wrote:
> > It seems this is the value most users set, so let's make it the default.
>
> I like the idea but would suggest to use ~/.gitexcludes instead.
> That way it doesn't clash with .gitignore if your $HOME is
> under git-control.
>
> Regards
>
> Stefan
I second this. I also keep my $HOME in git.
--
David
^ permalink raw reply
* Re: [PATCH 1/2] merge-recursive: point the user to commit when file would be overwritten.
From: Junio C Hamano @ 2009-11-20 18:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1258732767-12741-2-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> The commit-before-pull is well accepted in the DVCS community, but is
> confusing some new users. This should get them back in the right way when
> the problem occurs.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Don't these extra lines warrant "advice.*" option?
> ---
> merge-recursive.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index f55b7eb..d5e0819 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -172,9 +172,11 @@ static int git_merge_trees(int index_only,
> struct unpack_trees_options opts;
> static const struct unpack_trees_error_msgs msgs = {
> /* would_overwrite */
> - "Your local changes to '%s' would be overwritten by merge. Aborting.",
> + "Your local changes to '%s' would be overwritten by merge. Aborting:\n"
> + "Please, commit your changes or stash them before you can merge.",
> /* not_uptodate_file */
> - "Your local changes to '%s' would be overwritten by merge. Aborting.",
> + "Your local changes to '%s' would be overwritten by merge. Aborting:\n"
> + "Please, commit your changes or stash them before you can merge.",
> /* not_uptodate_dir */
> "Updating '%s' would lose untracked files in it. Aborting.",
> /* would_lose_untracked */
> --
> 1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply
* Re: [PATCH 0/3] "log --stdin" updates
From: Junio C Hamano @ 2009-11-20 17:59 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091120144030.GB5419@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 20, 2009 at 03:25:12AM -0800, Junio C Hamano wrote:
>
>> These three come on top of 61ab67a (Teach --stdin option to "log" family,
>> 2009-11-03), which gave "--stdin" to the log family of commands (e.g. log,
>> rev-list). The earlier patch allowed you to feed only the revs (which was
>> what gitk originally wanted), but after zero or more revs (one rev per
>> line), you can now feed a line that consists of "--" and then pathspecs
>> (one path per line).
>
> This looks like a good API feature, though I am curious about the
> missing "4/3" that was the motivation (of course, with a feature
> like this, it may be for your out-of-git script, but as I said, I am
> curious :) ). Is it a response to
>
> http://article.gmane.org/gmane.comp.version-control.git/133268
>
> ?
No. This series is a follow-up to $gmane/131971; I was suspicious that I
missed something for the API feature to be complete back then (and the
patch was not signed-off partly for that reason), and I found one thing
that was lacking.
^ permalink raw reply
* Re: [PATCH] bash completion: add space between branch name and status flags
From: Junio C Hamano @ 2009-11-20 17:53 UTC (permalink / raw)
To: Roman Fietze; +Cc: Shawn O. Pearce, git
In-Reply-To: <200911201309.16193.roman.fietze@telemotive.de>
Roman Fietze <roman.fietze@telemotive.de> writes:
> Hello Shawn, hello git list members,
>
> Wouldn't it improve the readability of the bash prompt, if there would
> be a space between the branch name and the status flags (dirty, stash,
> untracked)?
Perhaps.
> Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
> ---
> contrib/completion/git-completion.bash | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-
> completion.bash
> index bd66639..407176b 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -169,10 +169,12 @@ __git_ps1 ()
> fi
> fi
>
> + local f="$w$i$s$u$r"
I think this line and the two changes to printf below is a big improvement
(unless we are using f for something else---I didn't look). But I think
the next line is wrong.
> + f=${f:+ $f}
The $r string is designed to be used as suffix from the beginning and
always has "|" in front of it as a delimiter, so if there is no w/i/s/u
(and I suspect many people do not use GIT_PS1_SHOWDIRTYSTATE and friends,
and these are _always_ empty for them) the above will begin with "|".
There is no need to steal one column from a typeable width from the
command line in such a case.
> if [ -n "${1-}" ]; then
> - printf "$1" "$c${b##refs/heads/}$w$i$s$u$r"
> + printf "$1" "$c${b##refs/heads/}$f"
> else
> - printf " (%s)" "$c${b##refs/heads/}$w$i$s$u$r"
> + printf " (%s)" "$c${b##refs/heads/}$f"
> fi
> fi
> }
To implement your stated goal (dirty/stash/untracked), you probably want
to do this instead...
local f="$w$i$s$u"
f="${f:+ $f}$r"
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: bill lam @ 2009-11-20 16:25 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30911200755l16b306cey16efb42fe9ba27da@mail.gmail.com>
On Fri, 20 Nov 2009, Jonas Fonseca wrote:
> install-release-doc-man:
> for doc in $(MANDOC); do \
> git checkout origin/release $$doc; \
> done
> $(MAKE) install-doc-man
Thanks it works. Could you also commit this to git?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* [PATCH] git am/mailinfo: Don't look at in-body headers when rebasing
From: Lukas Sandström @ 2009-11-20 16:12 UTC (permalink / raw)
To: Jeff King; +Cc: Lukas Sandström, Philip Hofstetter, Junio C Hamano, git
In-Reply-To: <20091119153622.GC6877@coredump.intra.peff.net>
When we are rebasing we know that the header lines in the
patch are good and that we don't need to pick up any headers
from the body of the patch.
This makes it possible to rebase commits whose commit message
start with "From" or "Date".
Test vectors by Jeff King.
Signed-off-by: Lukas Sandström <luksan@gmail.com>
---
Jeff King wrote:
> On Thu, Nov 19, 2009 at 09:51:36AM +0100, Lukas Sandström wrote:
> Thanks, it did end up being a pretty small change. Though I think we may
> be better off with _both_ patches. Your patch protects the message
> absolutely during rebasing, and my patch improves the heuristic when
> applying non-rebase patches.
>
I looked a bit at using your extra safety check, but it would be a change
in behavior to only accept valid email adresses, and mailinfo
is riddled with corner cases. If this changed is made someone
will propably complain, saying that they rely on invalid dates in their
commit messages.
I don't know when to apply your stricter check whithout breaking any tests.
>> @@ -771,6 +772,8 @@ static int handle_commit_msg(struct strbuf *line)
>> return 0;
>>
>> if (still_looking) {
>> + if (!use_inbody_headers)
>> + still_looking = 0;
>> strbuf_ltrim(line);
>> if (!line->len)
>> return 0;
>
> Hmm. But we still end up in this conditional for the very first line.
> Which I guess happens to work because the first line we feed is
> presumably the empty blank line (but I didn't check). Still, wouldn't it
> be more clear as:
>
> if (use_inbody_headers && still_looking) {
> ...
>
> in which case still_looking simply becomes irrelevant when the feature
> is disabled?
When rebasing the first line passed to handle_commit_msg will be the blank
line between the headers and commit message. This should be removed. I
rewrote this part to make it a bit more obvious.
>
>> +From nobody Mon Sep 17 00:00:00 2001
>> +From: A U Thor <a.u.thor@example.com>
>> +Subject: check bogus body header (from)
>> +Date: Fri, 9 Jun 2006 00:44:16 -0700
>> +
>> +From: bogosity
>> + - a list
>> + - of stuff
>> +---
>
> Since your feature is meant to prevent us looking at inbody headers no
> matter if they are valid-looking or not, wouldn't a better test be to
> actually have:
>
> From: Other Author <other@example.com>
>
> Otherwise, you don't know if it is your feature blocking it, or my patch
> (if it gets applied on top).
>
I kept the tests as is for now, since they show the problem
originally reported.
/Lukas
builtin-mailinfo.c | 12 +++++++++++-
git-am.sh | 13 ++++++++++---
t/t5100-mailinfo.sh | 6 +++++-
t/t5100/info0015 | 5 +++++
t/t5100/info0015--no-inbody-headers | 5 +++++
t/t5100/info0016 | 5 +++++
t/t5100/info0016--no-inbody-headers | 5 +++++
t/t5100/msg0015 | 2 ++
t/t5100/msg0015--no-inbody-headers | 3 +++
t/t5100/msg0016 | 2 ++
t/t5100/msg0016--no-inbody-headers | 4 ++++
t/t5100/patch0015 | 8 ++++++++
t/t5100/patch0015--no-inbody-headers | 8 ++++++++
t/t5100/patch0016 | 8 ++++++++
t/t5100/patch0016--no-inbody-headers | 8 ++++++++
t/t5100/sample.mbox | 33 +++++++++++++++++++++++++++++++++
16 files changed, 122 insertions(+), 5 deletions(-)
create mode 100644 t/t5100/info0015
create mode 100644 t/t5100/info0015--no-inbody-headers
create mode 100644 t/t5100/info0016
create mode 100644 t/t5100/info0016--no-inbody-headers
create mode 100644 t/t5100/msg0015
create mode 100644 t/t5100/msg0015--no-inbody-headers
create mode 100644 t/t5100/msg0016
create mode 100644 t/t5100/msg0016--no-inbody-headers
create mode 100644 t/t5100/patch0015
create mode 100644 t/t5100/patch0015--no-inbody-headers
create mode 100644 t/t5100/patch0016
create mode 100644 t/t5100/patch0016--no-inbody-headers
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index c90cd31..3c4f075 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -26,6 +26,7 @@ static struct strbuf charset = STRBUF_INIT;
static int patch_lines;
static struct strbuf **p_hdr_data, **s_hdr_data;
static int use_scissors;
+static int use_inbody_headers = 1;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
@@ -774,10 +775,17 @@ static int handle_commit_msg(struct strbuf *line)
strbuf_ltrim(line);
if (!line->len)
return 0;
+ }
+
+ if (use_inbody_headers && still_looking) {
still_looking = check_header(line, s_hdr_data, 0);
if (still_looking)
return 0;
- }
+ } else
+ /* Only trim the first (blank) line of the commit message
+ * when ignoring in-body headers.
+ */
+ still_looking = 0;
/* normalize the log message to UTF-8. */
if (metainfo_charset)
@@ -1033,6 +1041,8 @@ int cmd_mailinfo(int argc, const char **argv, const char *prefix)
use_scissors = 1;
else if (!strcmp(argv[1], "--no-scissors"))
use_scissors = 0;
+ else if (!strcmp(argv[1], "--no-inbody-headers"))
+ use_inbody_headers = 0;
else
usage(mailinfo_usage);
argc--; argv++;
diff --git a/git-am.sh b/git-am.sh
index c132f50..96869a2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -289,7 +289,7 @@ split_patches () {
prec=4
dotest="$GIT_DIR/rebase-apply"
sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
-resolvemsg= resume= scissors=
+resolvemsg= resume= scissors= no_inbody_headers=
git_apply_opt=
committer_date_is_author_date=
ignore_date=
@@ -322,7 +322,7 @@ do
--abort)
abort=t ;;
--rebasing)
- rebasing=t threeway=t keep=t scissors=f ;;
+ rebasing=t threeway=t keep=t scissors=f no_inbody_headers=t ;;
-d|--dotest)
die "-d option is no longer supported. Do not use."
;;
@@ -448,6 +448,7 @@ else
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
echo "$scissors" >"$dotest/scissors"
+ echo "$no_inbody_headers" >"$dotest/no_inbody_headers"
echo "$GIT_QUIET" >"$dotest/quiet"
echo 1 >"$dotest/next"
if test -n "$rebasing"
@@ -495,6 +496,12 @@ t)
f)
scissors=--no-scissors ;;
esac
+if test "$(cat "$dotest/no_inbody_headers")" = t
+then
+ no_inbody_headers=--no-inbody-headers
+else
+ no_inbody_headers=
+fi
if test "$(cat "$dotest/quiet")" = t
then
GIT_QUIET=t
@@ -549,7 +556,7 @@ do
# by the user, or the user can tell us to do so by --resolved flag.
case "$resume" in
'')
- git mailinfo $keep $scissors $utf8 "$dotest/msg" "$dotest/patch" \
+ git mailinfo $keep $no_inbody_headers $scissors $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
stop_here $this
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 0279d07..ebc36c1 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 14'
+ test `cat last` = 16'
check_mailinfo () {
mail=$1 opt=$2
@@ -30,6 +30,10 @@ do
if test -f "$TEST_DIRECTORY"/t5100/msg$mail--scissors
then
check_mailinfo $mail --scissors
+ fi &&
+ if test -f "$TEST_DIRECTORY"/t5100/msg$mail--no-inbody-headers
+ then
+ check_mailinfo $mail --no-inbody-headers
fi
'
done
diff --git a/t/t5100/info0015 b/t/t5100/info0015
new file mode 100644
index 0000000..0114f10
--- /dev/null
+++ b/t/t5100/info0015
@@ -0,0 +1,5 @@
+Author:
+Email:
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0015--no-inbody-headers b/t/t5100/info0015--no-inbody-headers
new file mode 100644
index 0000000..c4d8d77
--- /dev/null
+++ b/t/t5100/info0015--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0016 b/t/t5100/info0016
new file mode 100644
index 0000000..38ccd0d
--- /dev/null
+++ b/t/t5100/info0016
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (date)
+Date: bogus
+
diff --git a/t/t5100/info0016--no-inbody-headers b/t/t5100/info0016--no-inbody-headers
new file mode 100644
index 0000000..f4857d4
--- /dev/null
+++ b/t/t5100/info0016--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (date)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/msg0015 b/t/t5100/msg0015
new file mode 100644
index 0000000..9577238
--- /dev/null
+++ b/t/t5100/msg0015
@@ -0,0 +1,2 @@
+- a list
+ - of stuff
diff --git a/t/t5100/msg0015--no-inbody-headers b/t/t5100/msg0015--no-inbody-headers
new file mode 100644
index 0000000..be5115b
--- /dev/null
+++ b/t/t5100/msg0015--no-inbody-headers
@@ -0,0 +1,3 @@
+From: bogosity
+ - a list
+ - of stuff
diff --git a/t/t5100/msg0016 b/t/t5100/msg0016
new file mode 100644
index 0000000..0d9adad
--- /dev/null
+++ b/t/t5100/msg0016
@@ -0,0 +1,2 @@
+and some content
+
diff --git a/t/t5100/msg0016--no-inbody-headers b/t/t5100/msg0016--no-inbody-headers
new file mode 100644
index 0000000..1063f51
--- /dev/null
+++ b/t/t5100/msg0016--no-inbody-headers
@@ -0,0 +1,4 @@
+Date: bogus
+
+and some content
+
diff --git a/t/t5100/patch0015 b/t/t5100/patch0015
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0015
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0015--no-inbody-headers b/t/t5100/patch0015--no-inbody-headers
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0015--no-inbody-headers
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0016 b/t/t5100/patch0016
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0016
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0016--no-inbody-headers b/t/t5100/patch0016--no-inbody-headers
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0016--no-inbody-headers
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 13fa4ae..de10312 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -650,3 +650,36 @@ index b0b5d8f..461c47e 100644
convert_to_utf8(line, charset.buf);
--
1.6.4.1
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+From: bogosity
+ - a list
+ - of stuff
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check bogus body header (date)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+Date: bogus
+
+and some content
+
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
--
1.6.4.4
^ permalink raw reply related
* [PATCH/resend] CVS Server: Support reading base and roots from environment
From: Phil Miller @ 2009-11-20 16:05 UTC (permalink / raw)
To: Git Maintainer; +Cc: Git Mailing List
The Gitosis single-account Git/ssh hosting system runs git commands
through git-shell after confirming that the connecting user is
authorized to access the requested repository. This works well for
upload-pack and receive-pack, which take a repository argument through
git-shell. This doesn't work so well for `cvs server', which is passed
through literally, with no arguments. Allowing arguments risks
sneaking in `--export-all', so that restriction should be maintained.
Despite that, passing a list of repository roots is necessary for
per-user access control by the hosting software, and passing a base
path improves usability without weakening security. Thus,
git-cvsserver needs to come up with these values at runtime by some
other means. Since git-shell preserves the environment for other
purposes, the environment can carry these arguments as well.
Thus, modify git-cvsserver to read $GIT_CVSSERVER_{BASE_PATH,ROOTS} in
the absence of equivalent command line arguments.
Signed-off-by: Phil Miller <mille121@illinois.edu>
---
git-cvsserver.perl | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 6dc45f5..9e58d2a 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -104,6 +104,7 @@ $log->info("--------------- STARTING -----------------");
my $usage =
"Usage: git cvsserver [options] [pserver|server] [<directory> ...]\n".
" --base-path <path> : Prepend to requested CVSROOT\n".
+ " Can be read from GIT_CVSSERVER_BASE_PATH\n".
" --strict-paths : Don't allow recursing into subdirectories\n".
" --export-all : Don't check for gitcvs.enabled in config\n".
" --version, -V : Print version information and exit\n".
@@ -111,7 +112,8 @@ my $usage =
"\n".
"<directory> ... is a list of allowed directories. If no directories\n".
"are given, all are allowed. This is an additional restriction, gitcvs\n".
- "access still needs to be enabled by the gitcvs.enabled config option.\n";
+ "access still needs to be enabled by the gitcvs.enabled config option.\n".
+ "Alternately, these directories may be specified in
GIT_CVSSERVER_ROOTS.\n";
my @opts = ( 'help|h|H', 'version|V',
'base-path=s', 'strict-paths', 'export-all' );
@@ -148,6 +150,23 @@ if ($state->{'export-all'} &&
!@{$state->{allowed_roots}}) {
die "--export-all can only be used together with an explicit whitelist\n";
}
+# Environment handling for running under git-shell
+if ($ENV{GIT_CVSSERVER_BASE_PATH}) {
+ if ($state->{'base-path'}) {
+ die "Cannot specify base path both ways.\n";
+ }
+ my $base_path = $ENV{GIT_CVSSERVER_BASE_PATH};
+ $state->{'base-path'} = $base_path;
+ $log->debug("Picked up base path '$base_path' from environment.\n");
+}
+if ($ENV{GIT_CVSSERVER_ROOTS}) {
+ if (@{$state->{allowed_roots}}) {
+ die "Cannot specify roots both ways: @ARGV\n";
+ }
+ my @allowed_root = split(',', $ENV{GIT_CVSSERVER_ROOTS});
+ $state->{allowed_roots} = [ @allowed_root ];
+}
+
# if we are called with a pserver argument,
# deal with the authentication cat before entering the
# main loop
--
1.5.6.3
^ permalink raw reply related
* [PATCH 1/2] merge-recursive: point the user to commit when file would be overwritten.
From: Matthieu Moy @ 2009-11-20 15:59 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <1258732767-12741-1-git-send-email-Matthieu.Moy@imag.fr>
The commit-before-pull is well accepted in the DVCS community, but is
confusing some new users. This should get them back in the right way when
the problem occurs.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
merge-recursive.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index f55b7eb..d5e0819 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -172,9 +172,11 @@ static int git_merge_trees(int index_only,
struct unpack_trees_options opts;
static const struct unpack_trees_error_msgs msgs = {
/* would_overwrite */
- "Your local changes to '%s' would be overwritten by merge. Aborting.",
+ "Your local changes to '%s' would be overwritten by merge. Aborting:\n"
+ "Please, commit your changes or stash them before you can merge.",
/* not_uptodate_file */
- "Your local changes to '%s' would be overwritten by merge. Aborting.",
+ "Your local changes to '%s' would be overwritten by merge. Aborting:\n"
+ "Please, commit your changes or stash them before you can merge.",
/* not_uptodate_dir */
"Updating '%s' would lose untracked files in it. Aborting.",
/* would_lose_untracked */
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [PATCH 2/2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Matthieu Moy @ 2009-11-20 15:59 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <1258732767-12741-1-git-send-email-Matthieu.Moy@imag.fr>
We explain the user why uncommited changes can be problematic with merge,
and point to "commit" and "stash" for the solution.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/user-manual.txt | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 269ec47..6b4a037 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1176,14 +1176,22 @@ How to merge
------------
You can rejoin two diverging branches of development using
-linkgit:git-merge[1]:
+linkgit:git-merge[1].
-------------------------------------------------
$ git merge branchname
-------------------------------------------------
merges the development in the branch "branchname" into the current
-branch. If there are conflicts--for example, if the same file is
+branch. Note that Git merges committed changes, but not the working
+tree itself. Therefore, if you have uncommitted changes touching the
+same files as the ones impacted by the merge, Git will refuse to
+proceed. Most of the time, you will want to commit your changes before
+you can merge, and if you don't, then linkgit:git-stash[1] can take
+these changes away while you're doing the merge, and reapply them
+afterwards.
+
+If there are conflicts--for example, if the same file is
modified in two different ways in the remote branch and the local
branch--then you are warned; the output may look something like this:
@@ -1679,7 +1687,7 @@ Sharing development with others
Getting updates with git pull
-----------------------------
-After you clone a repository and make a few changes of your own, you
+After you clone a repository and commit a few changes of your own, you
may wish to check the original repository for updates and merge them
into your own work.
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [RFC/PATCH 0/2] Explain newbies the "commit before pull" flow
From: Matthieu Moy @ 2009-11-20 15:59 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
A colleague of mine asked me "why do I need to commit before I can
pull", and I was about to send a link to the user manual, when I
noticed I couldn't find any explanation about that there.
This little patch serie propose a few more sentence in the user
manual, and a little more verbose error message for those who don't
read the docs.
I'm not sure the wording is the best we can do. Native-speakers and
Git gurus are welcome to improve it ;-).
Matthieu Moy (2):
merge-recursive: point the user to commit when file would be
overwritten.
user-manual: Document that "git merge" doesn't like uncommited
changes.
Documentation/user-manual.txt | 14 +++++++++++---
merge-recursive.c | 6 ++++--
2 files changed, 15 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Clemens Buchacher @ 2009-11-20 15:58 UTC (permalink / raw)
To: Adrian May; +Cc: git
In-Reply-To: <65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com>
On Fri, Nov 20, 2009 at 06:51:32PM +0800, Adrian May wrote:
> Git is just plain wrong, because you can't split or merge repositories
> or pull subtrees of them.
I think you made an unfortunate choice of words here, because as others have
mentioned, splitting and merging subtrees is implemented already. Maybe you
were talking about checking out or cloning subtrees. To date, none of the
distributed version control systems are capable of doing that. And that is
one of the reasons why we have wrapper scripts like repo (although IIRC repo
does a lot more than just that).
AFAICS, there is no fundamental reason why this should be difficult to
support. Clearly, there are some odd situations to deal with. For example,
how to deal with merge conflicts that happen outside of the subtree that's
currently available? How to detect (modified) moves of files into the
available subtree?
But we could simply fail in these cases. The workarounds currently in use
are not able to do this either.
> It doesn't have the kind of triggers you need to assert change control
> either, and these bolt-on scripts are just making life messy.
I don't understand what you mean here.
> Will somebody please finish git itself instead of working around it, or
> use a source control system that's up to the job.
There is a desire to do this in the git community, as documented in [1].
However, it appears to be hard enough to do so that people had rather
implement custom solutions such as git-submodules, which are probably just
good enough for them.
Clemens
[1] http://git.or.cz/gitwiki/SoC2009Ideas#NarrowandSparseclonesupport
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-20 15:55 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091120135004.GA3919@debian.b2j>
On Fri, Nov 20, 2009 at 08:50, bill lam <cbill.lam@gmail.com> wrote:
> On Fri, 20 Nov 2009, Jonas Fonseca wrote:
>> Build with asciidoc-8.4.5
> ..
>> Update asciidoc table syntax to the one supported by version 8.4.4
>
> sciidoc -aversion=0.15-dirty -asysconfdir=/usr/etc -b docbook -d manpage tigmanual.7.txt
> FAILED: /home/bill/src/tig/manual.txt: line 314: illegal [paradef-default] options: header: header
> make: *** [tigmanual.7.xml] Error 1
>
> May be the asciidoc 8.2.7 in debian lenny is not new enough. make install-doc
> failed with the above message. Any workaround other than upgrading asciidoc ?
No, not if you want to build the man pages yourself.
How about adding a script or a make rule to optionally install man
pages from the release branch. For example:
install-release-doc-man:
for doc in $(MANDOC); do \
git checkout origin/release $$doc; \
done
$(MAKE) install-doc-man
--
Jonas Fonseca
^ 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