* Re: git cherry-pick --continue?
From: Junio C Hamano @ 2010-02-10 22:34 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Jeff King, Git List
In-Reply-To: <fabb9a1e1002101423y79460afdn2bc31b117195ef42@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Wed, Feb 10, 2010 at 23:21, Junio C Hamano <gitster@pobox.com> wrote:
>> Having said all I did in the previous message, I think "am --continue"
>> would be a good addition.
>
> How about 'cherry-pick --resolved' though ;).
Changing the insn to suggest using "-C topic" when the original command
line was "git cherry-pick topic" would be a good addition, too. Currently
we suggest "-c" and abbreviated object name, neither of which is sensible.
While I think "--resolved" makes sense, I do not see much benefit, and it
largely depends on what you do. If you are suggesting to commit with what
is kept in $GIT_DIR/MERGE_MSG, I would actually recommend against it. The
message will have "Conflicts:" information but that is meaningless unless
you are recording from what context the commit was cherry-picked from at
the same time.
^ permalink raw reply
* Re: git cherry-pick --continue?
From: Sverre Rabbelier @ 2010-02-10 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git List
In-Reply-To: <7vpr4c200i.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Feb 10, 2010 at 23:34, Junio C Hamano <gitster@pobox.com> wrote:
> Changing the insn to suggest using "-C topic" when the original command
> line was "git cherry-pick topic" would be a good addition, too. Currently
> we suggest "-c" and abbreviated object name, neither of which is sensible.
I think it's sensible to use '-c' instead of '-C', just like 'git
rebase -i' lets you change the commit message after you resolve a
conflict.
> While I think "--resolved" makes sense, I do not see much benefit, and it
> largely depends on what you do. If you are suggesting to commit with what
> is kept in $GIT_DIR/MERGE_MSG, I would actually recommend against it. The
> message will have "Conflicts:" information but that is meaningless unless
> you are recording from what context the commit was cherry-picked from at
> the same time.
I'm not sure how to implement it, but I was thinking to just automate
the 'git commit -c ...' part. I don't like having to copy/paste some
instruction, so maybe we can record the original commit somewhere and
have 'git cherry-pick --resolve' be equivalent to 'git commit -c `cat
.git/CHERRY_PICK_CMT`', or somesuch?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC] submodule+shallow clone feature request
From: Johannes Schindelin @ 2010-02-10 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Schuyler Duveen, git
In-Reply-To: <7vsk983fi4.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 10 Feb 2010, Junio C Hamano wrote:
> Schuyler Duveen <sky@columbia.edu> writes:
>
> > My use case is deploying from a git repository, which would be even more
> > graceful with the following features:
> >
> > 1. When 'git clone' has both --recursive and --depth, then submodules
> > are also checked out shallow (for speed/bandwidth).
> >
> > 2. Some way to specify an override on .gitmodules sources. This is
> > because our .gitmodules includes public, read-only sources (github),
> > rather than our local repos we would prefer to deploy from (for the
> > purpose of reliability).
>
> These should be doable if you do not use --recursive, so I don't think
> they are insurmountable issues. I suspect many people would welcome
> such enhancements to the "git submodule" potty.
Yes. Note, though, that the problems of enhancing git-submodule are not
technical, as we can learn from the recent history, including the lack of
support for rebasing submodules (there _were_ patches!).
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] submodule+shallow clone feature request
From: Junio C Hamano @ 2010-02-10 23:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Schuyler Duveen, git
In-Reply-To: <alpine.DEB.1.00.1002102354010.20986@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Yes. Note, though, that the problems of enhancing git-submodule are not
> technical, as we can learn from the recent history, including the lack of
> support for rebasing submodules (there _were_ patches!).
Sorry I don't recall. Were they of 'next' quality? How well were they
reviewed?
^ permalink raw reply
* [ANNOUNCE] Git 1.6.6.2
From: Junio C Hamano @ 2010-02-10 23:41 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.6.6.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.6.2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.6.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.6.2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.6.2-1.fc11.$arch.rpm (RPM)
Git v1.6.6.2 Release Notes
==========================
Fixes since v1.6.6.1
--------------------
* recursive merge didn't correctly diagnose its own programming errors,
and instead caused the caller to segfault.
* The new "smart http" aware clients probed the web servers to see if
they support smart http, but did not fall back to dumb http transport
correctly with some servers.
* Time based reflog syntax e.g. "@{yesterday}" didn't diagnose a misspelled
time specification and instead assumed "@{now}".
* "git archive HEAD -- no-such-directory" produced an empty archive
without complaining.
* "git blame -L start,end -- file" misbehaved when given a start that is
larger than the number of lines in the file.
* "git checkout -m" didn't correctly call custom merge backend supplied
by the end user.
* "git config -f <file>" misbehaved when run from a subdirectory.
* "git cvsserver" didn't like having regex metacharacters (e.g. '+') in
CVSROOT environment.
* "git fast-import" did not correctly handle large blobs that may
bust the pack size limit.
* "git gui" is supposed to work even when launched from inside a .git
directory.
* "git gui" misbehaved when applying a hunk that ends with deletion.
* "git imap-send" did not honor imap.preformattedHTML as documented.
* "git log" family incorrectly showed the commit notes unconditionally by
mistake, which was especially irritating when running "git log --oneline".
* "git status" shouldn't require an write access to the repository.
Other minor documentation updates are included.
^ permalink raw reply
* No 1.7.0 tonight
From: Junio C Hamano @ 2010-02-10 23:43 UTC (permalink / raw)
To: git
I'll be sucked into a meeting tonight; I won't have enough time to do the
usual release engineering work for 1.7.0 carefully so it will be sometime
later this week.
Thanks.
^ permalink raw reply
* Re: [RFC] submodule+shallow clone feature request
From: Johannes Schindelin @ 2010-02-10 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Schuyler Duveen, git
In-Reply-To: <7v1vgszo16.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 10 Feb 2010, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Yes. Note, though, that the problems of enhancing git-submodule are
> > not technical, as we can learn from the recent history, including the
> > lack of support for rebasing submodules (there _were_ patches!).
>
> Sorry I don't recall. Were they of 'next' quality? How well were they
> reviewed?
Obviously not, otherwise you would have applied them, no?
OTOH I found the technical details rather trivial, so maybe they were
'next' quality, but there was another reason you did not apply them.
I just know that from my daily workflow, I deeply miss rebasing
submodules. But then, I listed the issues I have with submodules, and this
list was welcomed with unbelievable enthusiasm.
Ciao,
Dscho
^ permalink raw reply
* git svn hangs on a rebase or clone when presented with a large commit.
From: Stephen & Linda Smith @ 2010-02-11 1:25 UTC (permalink / raw)
To: git
I have to use git svn to pull from a subversion repository in a local git
repository. I don't have any local subversion repositories to debug the
problem that I will describe below.
I do a git svn clone (or if I've already done a clone an git svn rebase) from
the repository. There is one particular subversion commit that is quite
large (revision 15300). Anyway both the git svn clone and the git svn
rebase commands hang.
... - r15259 - r15300 - r15301 - ...
I know there are commits in the subversion repoistory beyond the bad
repository and I would like to be able do manually what git svn rebase would
do with the commit and then be able to run git svn rebase to get revisions
15301 and following.
Are the steps necessary to manually fetch 15300 so that I don't screw up
future git svn rebase commands documented?
^ permalink raw reply
* Re: git rebase -i and the reflog
From: Nicolas Pitre @ 2010-02-11 3:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e1002101419x40844a42s21108aaa849430c1@mail.gmail.com>
On Wed, 10 Feb 2010, Sverre Rabbelier wrote:
> Heya,
>
> I use "git rebase -i" a lot, and as a result the output from 'git log
> -g' and 'git reflog' is a tad messy. That is, it's (afaik) not
> possible to check that after my rebasing did not mess things up using
> something like 'git diff HEAD@{1}'. I could of course tag the old head
> or something, but that's not the only problem, due to the clutter it's
> hard to find genuine commits. What I want is a way to see HEAD's
> movement _excluding_ any rebase activity. So if I change history from
> A-o-B-C to A-o-B'-C', I want to see C and C' in the reflog, but not
> B', since B' is often actually identical to B, the only reason that it
> changed is that I did 'git rebase -i' on some far-back commit.
>
> Is there an existing solution to this?
What about looking at the reflog for the branch you're on instead of
HEAD? In the reflog space they're different.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-archive documentation: .gitattributes must be committed
From: Francois Marier @ 2010-02-11 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, git, Nguyen Thai Ngoc Duy
In-Reply-To: <7veiks7rux.fsf@alter.siamese.dyndns.org>
On 2010-02-10 at 12:33:58, Junio C Hamano wrote:
> +Note that attributes are by default taken from the `.gitattributes` files
> +in the tree that is being archived. If you want to tweak the way the
> +output is generated after the fact (e.g. you committed without adding an
> +appropriate export-ignore in its `.gitattributes`), adjust the checked out
> +`.gitattributes` file as necessary and use `--work-tree-attributes`
> +option. Alternatively you can keep necessary attributes that should apply
> +while archiving any tree in your `$GIT_DIR/info/attributes` file.
Looks good to me.
--
Francois Marier identi.ca/fmarier
http://feeding.cloud.geek.nz twitter.com/fmarier
^ permalink raw reply
* Problem adding a symlinkg
From: Arnaud Bailly @ 2010-02-11 6:17 UTC (permalink / raw)
To: git
Hello,
I am trying to add some symlink to git and got the following error:
error: readlink("protoc/Linux-x86-2.6.28/lib/libprotobuf-lite.so"): Invalid
argument
error: unable to index file protoc/Linux-x86-2.6.28/lib/libprotobuf-lite.so
fatal: adding files failed
I thought it was possible to add symlinks to git. What am I doing wrong ?
THanks for your help
Arnaud
--
View this message in context: http://n2.nabble.com/Problem-adding-a-symlinkg-tp4553010p4553010.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re* [RFC] submodule+shallow clone feature request
From: Junio C Hamano @ 2010-02-11 6:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Schuyler Duveen, git, Peter Hutterer
In-Reply-To: <alpine.DEB.1.00.1002110057180.20986@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 10 Feb 2010, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > Yes. Note, though, that the problems of enhancing git-submodule are
>> > not technical, as we can learn from the recent history, including the
>> > lack of support for rebasing submodules (there _were_ patches!).
>>
>> Sorry I don't recall. Were they of 'next' quality? How well were they
>> reviewed?
>
> Obviously not, otherwise you would have applied them, no?
>
> OTOH I found the technical details rather trivial, so maybe they were
> 'next' quality, but there was another reason you did not apply them.
Well, I spent some time digging the mail archive myself. I think you were
talking about this thread:
http://thread.gmane.org/gmane.comp.version-control.git/116918
If this is not the thread you were talking about, please discard/disregard
the remainder of this message, and give me a better pointer instead.
The thread ends with you asking me:
Junio, how about it? post 1.6.3 or not? It is a well contained change,
with little chance of breaking something, but offers a more sensible
workflow here.
and I said:
I am afraid it is a bit too late for "improvements" after -rc1.
People survived without the new feature until now, and they can wait a
bit longer for the next one....
Obviously, after that nothing happened. We have some people who send
reminders for good topics after the original thread died without producing
a visible result. I'd ask you to do the same (when you can---as everybody
else, you don't work full time on git; neither do I).
An honest answer to my question would have been "Yes, I reviewed it and
mentored the original author through a few cycles of revisions. After
that process the patch was of 'next' quality. This however happened
during the pre-release freeze, and unfortunately nobody (including you or
I) rememebered to bring up the issue again after the release to move
things forward. It fell through cracks."
Instead, what you wrote makes it sounds as if I blocked a technically
correct solution to a real problem on some political grounds, doesn't it?
What effect did you hope your insinuation to have on readers of this list?
It does not help to give a new person a false impression that it takes
more than producing a good solution to a real problem to contribute to the
project. Especially, the "falling through the crack" didn't have anything
to do with it being submodule changes. Please stop spreading FUD and try
to be constructive as others do.
To restart the discussion so that we can have it (if it is a good change)
after 1.7.0 ships, here is a pointer to the last revision of the patch.
http://article.gmane.org/gmane.comp.version-control.git/117394/raw
I didn't check if it needs rebasing to the recent codebase, but I expect
people who work with submodules in real life (I don't count) to comment on
it, and re-polish it into an applicable shape if necessary, by the time
post 1.7.0 cycle opens.
-- >8 --
From: Peter Hutterer <peter.hutterer@who-t.net>
Subject: Re: [PATCH/RESEND] git-submodule: add support for --rebase.
Date: Fri, 24 Apr 2009 09:06:38 +1000
'git submodule update --rebase' rebases your local branch on top of what
would have been checked out to a detached HEAD otherwise.
In some cases, detaching the HEAD when updating a submodule complicates
the workflow to commit to this submodule (checkout master, rebase, then
commit). For submodules that require frequent updates but infrequent
(if any) commits, a rebase can be executed directly by the git-submodule
command, ensuring that the submodules stay on their respective branches.
git-config key: submodule.$name.rebase (bool)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
> With this squashed in, I actually would not be too opposed to put this
> into 1.6.3, as it _is_ an improvement.
>
> -- snipsnap --
> [PATCH] To be squashed in
>
> This does three things:
>
> - add .gitmodules support for rebase,
> - use --bool for the git config calls for type checking, and
> - rename ambiguous t7404 to t7406.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Squashed in, thank you. One typo fixed in last testcase (does-not-mater ->
does-not-matter).
Documentation/git-submodule.txt | 14 ++++-
Documentation/gitmodules.txt | 3 +
git-submodule.sh | 33 ++++++++-
t/t7406-submodule-update.sh | 140 +++++++++++++++++++++++++++++++++++++++
4 files changed, 184 insertions(+), 6 deletions(-)
create mode 100755 t/t7406-submodule-update.sh
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 3b8df44..0286409 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git submodule' [--quiet] add [-b branch] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--] [<path>...]
+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--] [<path>...]
'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
'git submodule' [--quiet] foreach <command>
'git submodule' [--quiet] sync [--] [<path>...]
@@ -113,7 +113,8 @@ init::
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
- This will make the submodules HEAD be detached.
+ This will make the submodules HEAD be detached unless '--rebase' is
+ specified or the key `submodule.$name.rebase` is set to `true`.
+
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
@@ -177,6 +178,15 @@ OPTIONS
This option is only valid for the update command.
Don't fetch new objects from the remote site.
+--rebase::
+ This option is only valid for the update command.
+ Rebase the current branch onto the commit recorded in the
+ superproject. If this option is given, the submodule's HEAD will not
+ be detached. If a a merge failure prevents this process, you will have
+ to resolve these failures with linkgit:git-rebase[1].
+ If the key `submodule.$name.rebase` is set to `true`, this option is
+ implicit.
+
<path>...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index d1a17e2..7c22c40 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -30,6 +30,9 @@ submodule.<name>.path::
submodule.<name>.url::
Defines an url from where the submodule repository can be cloned.
+submodule.<name>.rebase::
+ Defines that the submodule should be rebased by default.
+
EXAMPLES
--------
diff --git a/git-submodule.sh b/git-submodule.sh
index 7c2e060..b7c9bdc 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -17,6 +17,7 @@ branch=
quiet=
cached=
nofetch=
+rebase=
#
# print stuff on stdout unless -q was specified
@@ -287,6 +288,11 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
+ test true != "$(git config -f .gitmodules --bool \
+ submodule."$name".rebase)" ||
+ git config submodule."$name".rebase true ||
+ die "Failed to register submodule path '$path' as rebasing"
+
say "Submodule '$name' ($url) registered for path '$path'"
done
}
@@ -314,6 +320,10 @@ cmd_update()
shift
nofetch=1
;;
+ -r|--rebase)
+ shift
+ rebase=true
+ ;;
--)
shift
break
@@ -332,6 +342,7 @@ cmd_update()
do
name=$(module_name "$path") || exit
url=$(git config submodule."$name".url)
+ rebase_module=$(git config --bool submodule."$name".rebase)
if test -z "$url"
then
# Only mention uninitialized submodules when its
@@ -352,6 +363,11 @@ cmd_update()
die "Unable to find current revision in submodule path '$path'"
fi
+ if test true = "$rebase"
+ then
+ rebase_module=true
+ fi
+
if test "$subsha1" != "$sha1"
then
force=
@@ -367,11 +383,20 @@ cmd_update()
die "Unable to fetch in submodule path '$path'"
fi
- (unset GIT_DIR; cd "$path" &&
- git-checkout $force -q "$sha1") ||
- die "Unable to checkout '$sha1' in submodule path '$path'"
+ if test true = "$rebase_module"
+ then
+ command="git-rebase"
+ action="rebase"
+ msg="rebased onto"
+ else
+ command="git-checkout $force -q"
+ action="checkout"
+ msg="checked out"
+ fi
- say "Submodule path '$path': checked out '$sha1'"
+ (unset GIT_DIR; cd "$path" && $command "$sha1") ||
+ die "Unable to $action '$sha1' in submodule path '$path'"
+ say "Submodule path '$path': $msg '$sha1'"
fi
done
}
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
new file mode 100755
index 0000000..3442c05
--- /dev/null
+++ b/t/t7406-submodule-update.sh
@@ -0,0 +1,140 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Red Hat, Inc.
+#
+
+test_description='Test updating submodules
+
+This test verifies that "git submodule update" detaches the HEAD of the
+submodule and "git submodule update --rebase" does not detach the HEAD.
+'
+
+. ./test-lib.sh
+
+
+compare_head()
+{
+ sha_master=`git-rev-list --max-count=1 master`
+ sha_head=`git-rev-list --max-count=1 HEAD`
+
+ test "$sha_master" = "$sha_head"
+}
+
+
+test_expect_success 'setup a submodule tree' '
+ echo file > file &&
+ git add file &&
+ test_tick &&
+ git commit -m upstream
+ git clone . super &&
+ git clone super submodule &&
+ (cd super &&
+ git submodule add ../submodule submodule &&
+ test_tick &&
+ git commit -m "submodule" &&
+ git submodule init submodule
+ ) &&
+ (cd submodule &&
+ echo "line2" > file &&
+ git add file &&
+ git commit -m "Commit 2"
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ git pull --rebase origin
+ ) &&
+ git add submodule &&
+ git commit -m "submodule update"
+ )
+'
+
+test_expect_success 'submodule update detaching the HEAD ' '
+ (cd super/submodule &&
+ git reset --hard HEAD~1
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ compare_head
+ ) &&
+ git submodule update submodule &&
+ cd submodule &&
+ ! compare_head
+ )
+'
+
+test_expect_success 'submodule update --rebase staying on master' '
+ (cd super/submodule &&
+ git checkout master
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ compare_head
+ ) &&
+ git submodule update --rebase submodule &&
+ cd submodule &&
+ compare_head
+ )
+'
+
+test_expect_success 'submodule update - rebase true in .git/config' '
+ (cd super &&
+ git config submodule.submodule.rebase true
+ ) &&
+ (cd super/submodule &&
+ git reset --hard HEAD~1
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ compare_head
+ ) &&
+ git submodule update submodule &&
+ cd submodule &&
+ compare_head
+ )
+'
+
+test_expect_success 'submodule update - rebase false in .git/config but --rebase given' '
+ (cd super &&
+ git config submodule.submodule.rebase false
+ ) &&
+ (cd super/submodule &&
+ git reset --hard HEAD~1
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ compare_head
+ ) &&
+ git submodule update --rebase submodule &&
+ cd submodule &&
+ compare_head
+ )
+'
+
+test_expect_success 'submodule update - rebase false in .git/config' '
+ (cd super &&
+ git config submodule.submodule.rebase false
+ ) &&
+ (cd super/submodule &&
+ git reset --hard HEAD^
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ compare_head
+ ) &&
+ git submodule update submodule &&
+ cd submodule &&
+ ! compare_head
+ )
+'
+
+test_expect_success 'submodule init picks up rebase' '
+ (cd super &&
+ git config submodule.rebasing.url git://non-existing/git &&
+ git config submodule.rebasing.path does-not-matter &&
+ git config submodule.rebasing.rebase true &&
+ git submodule init rebasing &&
+ test true = $(git config --bool submodule.rebasing.rebase)
+ )
+'
+
+test_done
--
1.6.3.rc1.2.gfa66a
^ permalink raw reply related
* Re: Re* [RFC] submodule+shallow clone feature request
From: Peter Hutterer @ 2010-02-11 6:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Schuyler Duveen, git
In-Reply-To: <7v8wb0l2f5.fsf@alter.siamese.dyndns.org>
On Wed, Feb 10, 2010 at 10:19:42PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 10 Feb 2010, Junio C Hamano wrote:
> >
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >>
> >> > Yes. Note, though, that the problems of enhancing git-submodule are
> >> > not technical, as we can learn from the recent history, including the
> >> > lack of support for rebasing submodules (there _were_ patches!).
> >>
> >> Sorry I don't recall. Were they of 'next' quality? How well were they
> >> reviewed?
> >
> > Obviously not, otherwise you would have applied them, no?
> >
> > OTOH I found the technical details rather trivial, so maybe they were
> > 'next' quality, but there was another reason you did not apply them.
>
> Well, I spent some time digging the mail archive myself. I think you were
> talking about this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/116918
>
> If this is not the thread you were talking about, please discard/disregard
> the remainder of this message, and give me a better pointer instead.
>
> The thread ends with you asking me:
>
> Junio, how about it? post 1.6.3 or not? It is a well contained change,
> with little chance of breaking something, but offers a more sensible
> workflow here.
>
> and I said:
>
> I am afraid it is a bit too late for "improvements" after -rc1.
> People survived without the new feature until now, and they can wait a
> bit longer for the next one....
>
> Obviously, after that nothing happened. We have some people who send
> reminders for good topics after the original thread died without producing
> a visible result. I'd ask you to do the same (when you can---as everybody
> else, you don't work full time on git; neither do I).
[...]
> To restart the discussion so that we can have it (if it is a good change)
> after 1.7.0 ships, here is a pointer to the last revision of the patch.
>
> http://article.gmane.org/gmane.comp.version-control.git/117394/raw
Thanks for CCing me, I'm not on the list at the moment.
FWIW, Johannes pinged me about this patch a few weeks after that, but after
revisiting it a few times I found some issues with it. Here's the email I
sent to Johannes on April 24, my apologies that this was a private email
only and did not reach the list.
"Sorry about the delay again, I've been a bit busy lately.
I've thought about it a bit more and tbh. I don't think this patch - even if
rebased - should be merged.
The original idea was that a module can be marked for auto-rebasing in
.gitmodules. The issue with that is that AFAIK git submodule does not store
branch info. So such auto-rebasing would only work provided it would be on
the master branch. Anything else would require a fancier script than my
patch including specifying which branch should be checked out in the
original clone.
Right now, I don't have the time to design such a patch and I'm not even
sure how much it is needed.
With git submodule foreach it's relatively simple to just do the auto-rebase
setting for all modules and I would not be surprised if the majority of
use-cases require auto-rebasing on all modules anyway.
Does that make sense?
"
So in this particular case the patchset was withdrawn by me for technical
reasons (and the lack of time to sort out the details). It should have
communicated better - again, my apologies for that.
Cheers,
Peter
^ permalink raw reply
* Re: git rebase -i and the reflog
From: Patrick Sudowe @ 2010-02-11 7:29 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e1002101419x40844a42s21108aaa849430c1@mail.gmail.com>
On Wednesday 2/10 2/10 11:19 PM, Sverre Rabbelier wrote:
> Heya,
>
> I use "git rebase -i" a lot, and as a result the output from 'git log
> -g' and 'git reflog' is a tad messy. That is, it's (afaik) not
> possible to check that after my rebasing did not mess things up using
> something like 'git diff HEAD@{1}'. I could of course tag the old head
> or something, but that's not the only problem, due to the clutter it's
> hard to find genuine commits. What I want is a way to see HEAD's
> movement _excluding_ any rebase activity. So if I change history from
> A-o-B-C to A-o-B'-C', I want to see C and C' in the reflog, but not
> B', since B' is often actually identical to B, the only reason that it
> changed is that I did 'git rebase -i' on some far-back commit.
>
> Is there an existing solution to this?
>
Since nobody else mentioned it on the list.
You could also use ORIG_HEAD.
merge, rebase and am (maybe others?) record the position of HEAD to
ORIG_HEAD before their operation.
So to check for the differences directly after one of these commands
a diff between HEAD and ORIG_HEAD should do.
I really liked the shortcut of ORIG_HEAD when I found out about it
just a couple days ago.
-Patrick
^ permalink raw reply
* Re: git-svn: Cannot lock the ref 'refs/remotes/tags/autotag_for_.'.
From: Tay Ray Chuan @ 2010-02-11 8:36 UTC (permalink / raw)
To: git
In-Reply-To: <20100209213929.GL3599@xorcom.com>
Hi,
On Wed, Feb 10, 2010 at 5:39 AM, Tzafrir Cohen <tzafrir.cohen@xorcom.com> wrote:
> Is there a way for me to skip some tags? I can avoid that specific tag.
have you tried --ignore-paths?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 8/6 v2] receive-pack: Send internal errors over side-band #2
From: Johannes Sixt @ 2010-02-11 8:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20100210173412.GG2747@spearce.org>
Shawn O. Pearce schrieb:
> +static void report_message(const char *prefix, const char *err, va_list params)
> +{
> + int sz = strlen(prefix);
> + char msg[4096];
> +
> + strncpy(msg, prefix, sz);
> + sz += vsnprintf(msg + sz, sizeof(msg) - sz, err, params);
> + if (sz > (sizeof(msg) - 1))
> + sz = sizeof(msg) - 1;
> + msg[sz++] = '\n';
Sorry, still no joy - the terminating NUL is missing (I should have
noticed this in your v1 already). I suggest to forgo the length check for
simplicity because this function is only called with data that is already
guaranteed to be less than 1000 bytes, i.e.:
strncpy(msg, prefix, sz);
/* data is guaranteed to fit due to packet length limit in
read_head_info() */
sz += vsprintf(msg + sz, err, params);
msg[sz++] = '\n';
msg[sz++] = '\0';
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/4] make_absolute_path(): Do not append redundant slash
From: Nguyen Thai Ngoc Duy @ 2010-02-11 10:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, João Carlos Mendes Luís, Junio C Hamano
In-Reply-To: <201002092010.43910.j6t@kdbg.org>
On Wed, Feb 10, 2010 at 2:10 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 9. Februar 2010, Nguyễn Thái Ngọc Duy wrote:
>> @@ -54,8 +54,9 @@ const char *make_absolute_path(const char *path)
>> if (len + strlen(last_elem) + 2 > PATH_MAX)
>> die ("Too long path name: '%s/%s'",
>> buf, last_elem);
>> - buf[len] = '/';
>> - strcpy(buf + len + 1, last_elem);
>> + if (*buf != '/' || buf[1] != '\0')
>> + buf[len++] = '/';
>
> Huh? You are adding a slash unless buf is exactly "/". That is, when buf
> is "/foo/" you still add a slash? That's not exactly avoiding redundancy.
> (Disclaimer: I didn't analyze the rest of the function whether my claim is
> true.)
buf is set by getcwd() so it should never be "/foo/" but doing
if (len && buf[len-1] != '/') buf[len++] = '/';
is probably clearer (and works on Windows too).
--
Duy
^ permalink raw reply
* Re: [PATCH 4/4] Add test for using Git at root of file system
From: Nguyen Thai Ngoc Duy @ 2010-02-11 10:01 UTC (permalink / raw)
To: João Carlos Mendes Luís; +Cc: git, Junio C Hamano, Johannes Sixt
In-Reply-To: <4B72B035.9080603@jonny.eng.br>
2010/2/10 João Carlos Mendes Luís <jonny@jonny.eng.br>:
>
>
> Nguyễn Thái Ngọc Duy wrote:
>>
>> This kind of test requires a throw-away root filesystem so that it can
>> play on. If you have such a system, go ahead, "chmod 777 /" and run
>> this test manually ("make test" with root permission won't work).
>>
>
> I've seen you have a prepare-chroot.sh file in there. Is it working or not?
> I mean, did you create a chrooted environment to test, or there was any
> problem with that?
That means if you already have a chroot environment, use it. Or you
can use prepare-chroot.sh to create a new chroot environment. Yes I
used prepare-chroot.sh for my testing.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/4] rev-parse: make --git-dir return /.git instead of //.git
From: Nguyen Thai Ngoc Duy @ 2010-02-11 10:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, João Carlos Mendes Luís, Junio C Hamano
In-Reply-To: <201002092018.55951.j6t@kdbg.org>
On Wed, Feb 10, 2010 at 2:18 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 9. Februar 2010, Nguyễn Thái Ngọc Duy wrote:
>> @@ -647,7 +647,7 @@ int cmd_rev_parse(int argc, const char **argv, const
>> char *prefix) }
>> if (!getcwd(cwd, PATH_MAX))
>> die_errno("unable to get current working directory");
>> - printf("%s/.git\n", cwd);
>> + printf("%s%s.git\n", cwd, *cwd == '/' && cwd[1] == '\0' ? "" : "/");
>
> On Windows, when you are in the root of a drive, then cwd is "C:/", i.e. there
> is a trailing slash just as in the Unix root directory. But you do not take
> care of this situation. That is, you would print "C://".
>
> How about:
>
> static inline int is_root_path(const char *path)
> {
> if (has_dos_drive_prefix(path))
> path += 2;
> while (is_dir_sep(*path))
> path++;
> return !*path;
> }
>
> and use it though-out your series?
>
> (Simplify the loop to 'return is_dir_sep(*path) && !path[1];' if you can
> assume that paths are nomalized.)
And return the length of root_path, so that I can use this function in
in setup_git_directory_gently() too. Yeah.
--
Duy
^ permalink raw reply
* XML Parsing Error: junk after document element
From: Siju George @ 2010-02-11 7:47 UTC (permalink / raw)
To: git
Hi,
I get this error when I take gitweb in a browser.
XML Parsing Error: junk after document element
Location: http://172.16.3.27/cgi-bin/gitweb.cgi
Line Number 28, Column 8:</html><!DOCTYPE HTML PUBLIC "-//IETF//DTD
HTML 2.0//EN">
-------^
How can I solve it?
Thanks
--Siju
^ permalink raw reply
* Re: git diff-index with relative git-dir does not work
From: Nguyen Thai Ngoc Duy @ 2010-02-11 10:35 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87wrymwo5a.wl@dns1.atmark-techno.com>
On Tue, Feb 9, 2010 at 8:10 PM, Yasushi SHOJI > In the diff-index
case, it, indeed, has RUN_SETUP explicitly
> set. however, it does not have NEED_WORK_TREE set. And, this is
> correct in the current semantics because diff-index is a tool to
> compare the index and the object store. it does not need a work tree.
Unless --cached is given, work tree is needed. I'm not saying that
diff-index is bug-free. But the bug you described is not relevant to
this.
> However, diff-index is used in describe which need a work tree if
> --dirty is given. That means that diff-index might be called
> with --work-tree.
Yes. And git-describe calls git-diff-index correctly, i.e. without --cached.
>> > In that case, we must change the setup functions signature to
>> > allow marking "not interested" or something.
>>
>> I'm not sure I get your idea.
>
> Given that in the current form of git, many built-in command is called
> by many other built-in commands. It is hard to predict what is needed
> and what's not. Plus, --git-dir and --work-tree are options to git
> itself not built-in's. So, I thought it might be a good idea to call,
> say, setup_work_tree_with_abs_path(), regardless of NEED_WORK_TREE, to
> explicitly setup run time environment before any other part of the
> code call, say, open_sha1_file.
The thing is not every command expect cwd to be moved to top
directory. In other words, they don't care about the prefix argument
being passed to it. So you would need go go through all commands
before doing that.
By the way, are you working on a patch for the diff-index bug?
--
Duy
^ permalink raw reply
* Re: XML Parsing Error: junk after document element
From: Jakub Narebski @ 2010-02-11 11:01 UTC (permalink / raw)
To: Siju George; +Cc: git
In-Reply-To: <b713df2c1002102347g70cc212et21d507d44bb5aead@mail.gmail.com>
Siju George <sgeorge.ml@gmail.com> writes:
> Hi,
>
> I get this error when I take gitweb in a browser.
>
> XML Parsing Error: junk after document element
> Location: http://172.16.3.27/cgi-bin/gitweb.cgi
> Line Number 28, Column 8:</html><!DOCTYPE HTML PUBLIC "-//IETF//DTD
> HTML 2.0//EN">
> -------^
>
> How can I solve it?
Which version of gitweb?[1] Which version of git?[2] What web server?
Which version of CGI.pm is used by web server?[3]
The included fragment after closing '</html>' tag doesn't look like
something coming from gitweb, as gitweb uses XHTML 1.0 DTD since it's
first version.
Try to view source, or use different web browser that doesn't do
strict XML validation to find the source of this error.
If everything else fals, you can always edit gitweb.cgi to comment out
content-type negotiation, to always serve as text/html mimetype -
which should torn off XML validation, as below:
my $content_type;
# require explicit support from the UA if we are to send the page as
# 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
# we have to do this because MSIE sometimes globs '*/*', pretending to
# support xhtml+xml but choking when it gets what it asked for.
# Disable content-type negotiation when caching (use mimetype good for all).
#if (defined $cgi->http('HTTP_ACCEPT') &&
# $cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ &&
# $cgi->Accept('application/xhtml+xml') != 0) {
# $content_type = 'application/xhtml+xml';
#} else {
$content_type = 'text/html';
#}
The commands below are _examples_ only:
[1] grep -F 'our $version' /var/www/cgi-bin/gitweb.cgi
[2] git --version
[3] perl -MCGI -le 'print $CGI::VERSION'
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Problem adding a symlinkg
From: Alex Riesen @ 2010-02-11 12:01 UTC (permalink / raw)
To: Arnaud Bailly; +Cc: git
In-Reply-To: <1265869060330-4553010.post@n2.nabble.com>
On Thu, Feb 11, 2010 at 07:17, Arnaud Bailly <abailly@oqube.com> wrote:
>
> I am trying to add some symlink to git and got the following error:
>
> error: readlink("protoc/Linux-x86-2.6.28/lib/libprotobuf-lite.so"): Invalid argument
Is the file in fact a symlink? Maybe it was replaced by a file while
Git was adding it?
If it is reproducable, could you strace "git add" and post the trace here?
^ permalink raw reply
* Re: [PATCH 3/4] Support working directory located at root
From: Nguyen Thai Ngoc Duy @ 2010-02-11 12:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <201002092019.45134.j6t@kdbg.org>
On 2/10/10, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 9. Februar 2010, Nguyễn Thái Ngọc Duy wrote:
> > I said I would have code change for DOS drive too. But I take it back.
> > Supporting GIT_DIR=C:\.git might be easy, GIT_DIR=C:.git is not.
>
>
> One does not set GIT_DIR=C:.git; it would be insane because it means ".git in
> an unpredictable directory somewhere on drive C". It would be great to
> support GIT_DIR=C:/.git
A bit off topic, but make_relative_path() may need more care for the
Windows port. I thought of making relative path between C:/foo and
D:/bar but it should work well for that case. //machine/share1/foo and
//machine/share2/bar may fail though.
--
Duy
^ permalink raw reply
* Re: Completion of error handling
From: Markus Elfring @ 2010-02-11 13:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.1002021324290.1681@xanadu.home>
>
> What is the likelihood for those function calls to actually fail?
>
How do you think about the usual design choices that are described in
the article "Exception Handling Alternatives" by Detlef Vollmann.
http://accu.org/index.php/journals/546
I propose to write pointcuts for all functions that can return values.
Some corresponding error codes are checked already. But there a places
in the source files with open issues for complete software robustness.
Are there any chances to encapsulate more cross-cutting concerns as
reusable aspects?
Would you like to integrate tools like the following into your software
development process?
- AspectC++
http://aspectc.org/
- ACC
http://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All
- Coccinelle
http://coccinelle.lip6.fr/
Regards,
Markus
^ 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