* Re: Git SVN Rebranching Issue
From: Eric Wong @ 2008-11-06 9:39 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Dmitry Potapov, Matt Kern, git
In-Reply-To: <32541b130811041640x18e3bbfewa639df356ff7561e@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> wrote:
> On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Dmitry Potapov <dpotapov@gmail.com> wrote:
> >> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
> >> >
> >> > Short answer: you can use grafts to remove parents.
> >>
> >> Using grafts requires some cautious, especially when it is used to make
> >> some commits unreachable, because git gc can remove unreachable commits.
> >> Also, a repository with grafts cannot be cloned. So using grafts looks
> >> like more as workaround rather a real solution.
> >
> > I don't think extra history is harmful at all, so the grafts could even
> > be temporary. AFAIK, the extra history is only an aesthetic issue in
> > visualizers (and I actually like to see it myself).
>
> But it's *lying* history in this case; it doesn't reflect what really
> happened in svn *or* in real life. I'd say lying history is most
> often harmful. "git blame" and "git log" will lie in this case, for
> example.
Maybe, but I don't find having a choice to follow _either_:
a) copy history (the REAL history)
b) the name history (faked)
I've had to deal with repositories that recycled branch names for a
while now and it hasn't been an issue for me nor anybody else
using git svn on them.
git log --first-parent exists for following copy history, too.
> >> Would it not be better to save the old branch using "@SVN-NUMBER" as
> >> suffix? Thus, those do not need the old branch can easily delete it.
> >
> > That would require renaming _existing_ branches to their "@SVN-NUMBER"
> > name; which would break mechanisms for tracking branches based on
> > refname.
>
> Well, you wouldn't have to rename the existing branch. You would
> simply create the new @SVN-NUMBER branch when it became clear that
> that commit is no longer reachable from the undecorated branch ref.
> Isn't that why the @SVN-NUMBER branches are needed in the first place?
Making @SVN-NUMBER branches for new/latest branches is even more
confusing. That would mean the user would have to remember the
@SVN-NUMBER every time they wanted to do operations with the
recycled branch.
The current use of @SVN-NUMBER in branches are only used when following
parents (when repositories are rearranged). In retrospect, it's
probably possible to for git-svn to not make them user-visible (I seem
to recall they made development/debugging/testing easier in the past,
though).
> As for tracking branches based on refname, it seems like the current
> behaviour of pretending to merge histories together wouldn't work too
> well anyway. For someone pulling from the messed-up branch, they
> really *will* need to rewind and re-pull, since that's exactly what
> happened in svn. I don't think git has any chance of doing this
> automatically just because of a new commit with two parents.
"git svn rebase" and "git log ..$RECYCLED" both work. non-FF/non-squash
pulls won't, of course.
> Disclaimer: I haven't run into any of this myself since I don't
> recycle branch names in svn :)
Lucky you :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Jeff King @ 2008-11-06 8:42 UTC (permalink / raw)
To: Suraj N. Kurapati; +Cc: git
In-Reply-To: <200811050959.25824.sunaku@gmail.com>
On Wed, Nov 05, 2008 at 09:59:25AM -0800, Suraj N. Kurapati wrote:
> Allows the user to answer 'Stage this hunk' questions with a
> single keypress, just like in Darcs. Previously, the user was
> forced to press the Return key after every choice they made.
> This quickly becomes tiring, burdensome work for the fingers.
I think this is a reasonable goal, but I have a few questions/concerns.
- There are three versions of your patch, but nobody has commented.
Clearly we can see what changed, but it is not clear what advantage
one patch has over the other. Care to elaborate?
- Term::ReadKey, while common, is not part of base perl. So I think
using it needs to be conditional, and on systems without it we can
degrade to the current behavior.
- There's no facility in your patch for restoring the terminal if we
break out of the loop in an unexpected way (e.g., via the user
hitting ^C).
- This only enhances one particular input, the patch loop. It is
probably worth being consistent and allowing these behavior for other
menus (though the numeric inputs are a bit trickier).
-Peff
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Karl Hasselström @ 2008-11-06 8:37 UTC (permalink / raw)
To: Christian MICHON; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <46d6db660811041430l74d9a100kc15ac46dea8ff63f@mail.gmail.com>
On 2008-11-04 23:30:56 +0100, Christian MICHON wrote:
> note the merge can work, but it's still done in 2 steps. :(
> thanks for suggesting this.
If it had worked, you'd have gotten just one merge commit. What you
want to do is entirely possible, but it seems the high-level commands
were not designed with your use-case in mind.
Another thing you could try is to merge the two branches separately,
getting a history like this:
p1----\
\
p2---A--B
/
p3--
And then use grafts to convince git that B has parents p1, p2, and p3
(instead of its actual parents p1 and A). (Grep for "graft" in the
Documentation directory.)
And then use git-filter-branch to rewrite history so that the grafted
history becomes the real history.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Added test case for mirror to not push stash refs
From: Sverre Rabbelier @ 2008-11-06 8:34 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <1225942397-20513-1-git-send-email-david@statichacks.org>
> + git push --mirror up
> + )
> +'
I don't quite get how this works, I don't see a test here anywhere to
actually test that the stash refs were not pushed?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: let git-diff allow patch to delete empty files?
From: Sam Liddicott @ 2008-11-06 8:30 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20081106060940.6117@nanako3.lavabit.com>
* Nanako Shiraishi wrote, On 05/11/08 21:09:
> Quoting "Sam Liddicott" <sam@liddicott.com>:
>
>
>> In some cases "patch" cannot apply diff's generated using git-diff, I've
>> had a "git diff" output look like this when an empty file was removed as
>> the only change:
>>
>
> Even if you do not use git to manage your changes, you can use "git apply" from outside of a git repository as a replacement for "patch".
>
>
Good tip, thanks.
In this case it is rpmbuild that is doing the patching, and making git a
build-requires would not be popular.
Sam
^ permalink raw reply
* [PATCH] Added test case for mirror to not push stash refs
From: david @ 2008-11-06 3:33 UTC (permalink / raw)
To: git; +Cc: David Bryson
In-Reply-To: <20081028212327.GA25358@sigill.intra.peff.net>
From: David Bryson <david@statichacks.org>
This test case checks to make sure mirror does not push stashed refs
---
t/t5517-push-mirror.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index ea49ded..bb263cd 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -123,6 +123,16 @@ test_expect_success 'push mirror adds, updates and removes branches together' '
'
+test_expect_success 'push mirror does not push stash refs' '
+
+ mk_repo_pair &&
+ (
+ cd master &&
+ echo foo >foo && git add foo && git commit -m 'foo' &&
+ echo bar >foo && git stash save 'WIP' &&
+ git push --mirror up
+ )
+'
# TAG tests
test_expect_success 'push mirror creates new tags' '
--
1.6.0.1
^ permalink raw reply related
* Re: [PATCH (MINGW) Resend] Windows: Make OpenSSH properly detect tty detachment.
From: Johannes Sixt @ 2008-11-06 7:35 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <200811022011.13970.angavrilov@gmail.com>
Alexander Gavrilov schrieb:
> Apparently, CREATE_NO_WINDOW makes the OS tell the process
> that it has a console, but without actually creating the
> window. As a result, when git is started from GUI, ssh
> tries to ask its questions on the invisible console.
>
> This patch uses DETACHED_PROCESS instead, which clearly
> means that the process should be left without a console.
> The downside is that if the process manually calls
> AllocConsole, the window will appear. A similar thing
> might occur if it calls another console executable.
The latest "What's cooking in git.git" report still doesn't mention this
patch. The reason might be that you mention some scary downsides in this
paragraph. I think you should either not mention the downsides, or
describe further why they do not make a difference in our case:
- We never call AllocConsole(). If some third-party program calls it, then
it gets what it requested. (But, yes, the behavior would indeed be
different from what it used to be.)
- There are two possible circumstances when another console executable is
called:
* A program that has no console - e.g. git-gui - runs a git process.
Then we are entering the "then" branch, and the new process is started
with DETACH_PROCESS. No new console window appears.
* A program that already has a console runs a git process. Then we are
entering the "else" branch, and we do not change the process flags nor are
we requesting a new console. No new console window appears.
I'm using this patch since weeks without noticing any downsides.
-- Hannes
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
> Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
>
> This patch appears to have been overlooked, so I resend
> it just in case. It fixes a long standing problem in msysgit.
>
> -- Alexander
>
> compat/mingw.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 1e29b88..b6fcf69 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -586,12 +586,16 @@ static pid_t mingw_spawnve(const char *cmd, const char **argv, char **env,
> * would normally create a console window. But
> * since we'll be redirecting std streams, we do
> * not need the console.
> + * It is necessary to use DETACHED_PROCESS
> + * instead of CREATE_NO_WINDOW to make ssh
> + * recognize that it has no console.
> */
> - flags = CREATE_NO_WINDOW;
> + flags = DETACHED_PROCESS;
> } else {
> /* There is already a console. If we specified
> - * CREATE_NO_WINDOW here, too, Windows would
> + * DETACHED_PROCESS here, too, Windows would
> * disassociate the child from the console.
> + * The same is true for CREATE_NO_WINDOW.
> * Go figure!
> */
> flags = 0;
^ permalink raw reply
* [PATCH v2] git-svn: proper detection of bare repositories
From: Deskin Miller @ 2008-11-06 5:07 UTC (permalink / raw)
To: Eric Wong; +Cc: git, gitster
In-Reply-To: <20081104083015.GA14405@untitled>
On Tue, Nov 04, 2008 at 12:30:15AM -0800, Eric Wong wrote:
> How about using git_cmd_try instead?
>
> The Error.pm try/catch stuff makes me a bit uncomfortable. I realize
> it's (unfortunately) in Git.pm; but I'd rather keep it confined there so
> we can more easily remove it later if someone were inclined.
Yeah, major thinko; I read the Git(3pm) manpage, looked at git_cmd_try, and for
some reason thought that it wasn't what I want. But it's exactly what I want.
Deskin Miller
-- 8< --
When in a bare repository (or .git, for that matter), git-svn would fail
to initialise properly, since git rev-parse --show-cdup would not output
anything. However, git rev-parse --show-cdup actually returns an error
code if it's really not in a git directory.
Fix the issue by checking for an explicit error from git rev-parse, and
setting $git_dir appropriately if instead it just does not output.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
git-svn.perl | 12 +++++++-----
t/t9100-git-svn-basic.sh | 9 +++++++++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 56238da..829a323 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -214,11 +214,13 @@ unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
"but it is not a directory\n";
}
my $git_dir = delete $ENV{GIT_DIR};
- chomp(my $cdup = command_oneline(qw/rev-parse --show-cdup/));
- unless (length $cdup) {
- die "Already at toplevel, but $git_dir ",
- "not found '$cdup'\n";
- }
+ my $cdup = undef;
+ git_cmd_try {
+ $cdup = command_oneline(qw/rev-parse --show-cdup/);
+ $git_dir = '.' unless ($cdup);
+ chomp $cdup if ($cdup);
+ $cdup = "." unless ($cdup && length $cdup);
+ } "Already at toplevel, but $git_dir not found\n";
chdir $cdup or die "Unable to chdir up to '$cdup'\n";
unless (-d $git_dir) {
die "$git_dir still not found after going to ",
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 843a501..fdbc23a 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -265,4 +265,13 @@ test_expect_success 'able to set-tree to a subdirectory' "
test -z \"\`git diff refs/heads/my-bar refs/remotes/bar\`\"
"
+test_expect_success 'git-svn works in a bare repository' '
+ mkdir bare-repo &&
+ ( cd bare-repo &&
+ git init --bare &&
+ GIT_DIR=. git svn init "$svnrepo" &&
+ git svn fetch ) &&
+ rm -rf bare-repo
+ '
+
test_done
--
1.6.0.3.524.g47d14
^ permalink raw reply related
* Re: fetch --tags --no-tags
From: Pau Garcia i Quiles @ 2008-11-06 3:55 UTC (permalink / raw)
To: git
In-Reply-To: <20081106044206.az9hgqffqccgo4gk@www.elpauer.org>
Quoting Pau Garcia i Quiles <pgquiles@elpauer.org>:
> Hello,
>
> Why doesn't 'git fetch --tags --no-tags' not return an error?
One too many negations in that sentence :-)
Just in case the question was not clear: "why does 'git fetch --tags
--no-tags' not return an error?"
>
> It looks like it does nothing and, in fact, allowing --tags and
> --no-tags seems a contradiction to me!
>
> Thank you.
majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* fetch --tags --no-tags
From: Pau Garcia i Quiles @ 2008-11-06 3:42 UTC (permalink / raw)
To: git
Hello,
Why doesn't 'git fetch --tags --no-tags' not return an error?
It looks like it does nothing and, in fact, allowing --tags and
--no-tags seems a contradiction to me!
Thank you.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Deskin Miller @ 2008-11-06 3:24 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <buoiqr18tdk.fsf@dhapc248.dev.necel.com>
On Thu, Nov 06, 2008 at 11:45:27AM +0900, Miles Bader wrote:
> Is there any easy way to cherry pick a _range_ of commits from some other
> branch to the current branch, instead of just one?
>
> I thought maybe git-rebase could be coerced to do this somehow, but I
> couldn't figure a way.
Rebase is exactly what you want. Given something like this:
o--o--o--A--B--C--o--o--X
\
o--o--D
where you want A, B, C to go on top of D:
$ git checkout -b newbranch C
$ git rebase --onto D ^A
newbranch will have <...> --D--A--B--C
Hope that helps,
Deskin Miller
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Jakub Narebski @ 2008-11-06 3:08 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811060014.57046.fg@one2team.net>
Francis Galiegue <fg@one2team.net> writes:
> Since my first email where I said that we wanted to migrate from CVS to a
> distributed SCM, we have had a lot of discussions with developers and my
> chief (which happens to be a developer too). We have come to the following
> conclusions:
>
> * git has credentials (heck, it "runs" the Linux kernel, Wine,
> Samba, and other);
The main contenders among top OSS version control systems seems to be
Git, Mercurial and Bazaar-NG for distributed SCM, and Subversion for
centralized SCM.
> * the "distributed" part of it is indeed an advantage (planned
> developments with huge technical/functional impacts);
> * 52 CVS modules, fine; but then this can become one and 52
> subdirectories in them and still act as separate modules from
> the build system point of view (which I have implemented, so
> I can change it);
I think that those CVS modules should become separate repositories,
perhaps joined together using submodules. This is one of more
difficult things during conversion.
Note that in Git commits are always whole tree (whole project)
commits.
> * second: even though this may be a "non problem", we use Bonsai,
> which has the ability to see what was commited by whom, given a time
> interval (from d1 to d2): the base gitweb allows to search by
> commiter, which is good, but it has no date boundaries: do tools
> exist for git that can do this? If not, that wouldn't be a big deal,
> however...
First, there are more web interfaces than gitweb, see
http://git.or.cz/gitweb/InterfacesFrontendsAndTools
Second, you can do this from command line, using combination of commit
limiting a..b and a...b, or --since=<date> or --after=<date> and
--before=<date>, commit message searching --author, --committer, and
--grep, and path limiting "git log -- <pathspec>".
Third, it would be not that hard to add more advanced search support
to gitweb; this is even one of planned features.
> * third: also Bonsai-related; Bonsai can link to Bugzilla by
> matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
> this built-in? (haven't looked yet) Is this planned, or has it been
> discussed and been considered not worth the hassle?
This is (under name of 'committags') in gitweb TODO; gitweb-xmms2
support this IIRC or supported this (for Mantis and not Bugzilla
though...)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* multiple-commit cherry-pick?
From: Miles Bader @ 2008-11-06 2:45 UTC (permalink / raw)
To: git
Is there any easy way to cherry pick a _range_ of commits from some other
branch to the current branch, instead of just one?
I thought maybe git-rebase could be coerced to do this somehow, but I
couldn't figure a way. [Using git-rebase would be nice because of all the
useful tools it provides, e.g., the --abort, --continue, and -i options.]
Thanks,
-Miles
--
P.S. All information contained in the above letter is false,
for reasons of military security.
^ permalink raw reply
* Workflow for sharing changes on top of often-rebased work
From: Mike Mazur @ 2008-11-06 1:57 UTC (permalink / raw)
To: git
Hi,
I have a set of changes on top of an SVN tree I'm tracking with git.
The SVN changes regularly, and I like to keep my changes up-to-date as
well. The branch containing my changes lives on my workstation, but
also in a remote repo so I can also work from my laptop, and others can
look at my work.
Here's my current workflow:
First, I clone the SVN repo on my workstation:
$ git svn clone ssh://remote/svn repo
$ cd repo
I then created a bare repo on a server (git://remote/repo) which is how
I share my changes between my workstation, laptop, and others. In my
repo, I add this remote location as origin. Occasionally I will rebase
my master against SVN and push this to the server:
$ git remote add origin git://remote/repo
$ git remote update
$ git checkout master
$ git svn rebase
$ git push origin master:master
Now, to do my work, I made a branch based on master in which my changes
will live:
$ git branch my_work master
$ git checkout my_work
Then I hack away and have a bunch of commits. I publish this branch on
my server:
$ git checkout my_work
$ git push origin my_work # create branch my_work in git://remote/repo
Eventually, I'd like to rebase this work on top of the latest SVN
revision. First I update my master branch against SVN:
$ git checkout master
$ git svn rebase
$ git push origin master:master
And then I rebase my work on top of that:
$ git checkout my_work
$ git rebase master
# resolve conflicts
$ git rebase --continue
At this point, I'd like to push my_work to the server:
$ git checkout my_work
$ git push origin my_work:my_work
To git://remote/repo
! [rejected] my_work -> my_work (non-fast forward)
error: failed to push some refs to 'git://remote/repo'
What's the proper way to do this?
I've read a few threads in the archives and came across an email by
Junio[1] that shows how using `git push --force` and setting
"receive.denynonfastforwards = false" on the remote repo will allow me
to push these changes. Is this the best way forward? If it is, how do I
(or others) update the my_work branch after a non-fast forward push to
the remote repo?
Your insights greatly appreciated!
Mike
[1] http://marc.info/?l=git&m=119540948816950&w=2
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Francis Galiegue @ 2008-11-06 1:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081105234425.GA2932@spearce.org>
[...]
> > > > * "git stash": is it supported?
> > >
> > > Not in Eclipse, no.
> >
> > What do you mean by this?
>
> I mean there's no implementation of git stash. Eclipse doesn't
> support git stash, the notion of the stash, the branch the stash
> is on. Its not in the Eclipse plugin.
>
While I'm a total newbie to Eclipse, and not that fluent with Java, this looks
surprising. Is it really Eclipse that is at fault here? Eclipse saves its
workspace (whatever it means to "save a workspace") when it exits, isn't
there an interface that you can implement that does "partial" saves, hence
git stashes?
> > > > * can you "copy" a commit, or even a set of commits, and
> > > > "cherry-pick" them into another branch? Or even rebase a branch onto
> > > > antoher?
> > >
> > > Not in Eclipse, no.
> >
> > Same question... What exactly is the problem with Eclipse wrt this kind
> > of operation?
>
> Its also not implemented in the eclipse UI.
Eclipse has the ability to apply patches AFAIK... Even though this may not be
equivalent to a git cherry-pick, wouldn't there be a way to extract at least
the diffs and commit messages and apply?
--
fge
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Francis Galiegue @ 2008-11-06 1:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20081105235035.GA10544@machine.or.cz>
Le Thursday 06 November 2008 00:50:35 Petr Baudis, vous avez écrit :
> Hi,
>
> On Thu, Nov 06, 2008 at 12:14:56AM +0100, Francis Galiegue wrote:
> > * second: even though this may be a "non problem", we use Bonsai, which
> > has the ability to see what was commited by whom, given a time interval
> > (from d1 to d2): the base gitweb allows to search by commiter, which is
> > good, but it has no date boundaries: do tools exist for git that can do
> > this? If not, that wouldn't be a big deal, however...
>
> git log --since='2 months ago' --until='1 month ago'
>
> There is no gitweb functionality for this right now, but I think an
> implementation of that would be welcome in principle.
>
Well, right now, the search field is only a... field. Implementing such a
change would require a whole search page... I don't think anyone would want
to pollute the bare-bones page with more fields if they're of no use 90+% of
the time.
A search page would make sense, I guess, since the date criterion is not the
only one that you could use... But what other criteria would be useful? And
then, if a search page is implemented, what of the current dropdown list?
Drop it altogether and put a "Search commits..." link instead?
> > * third: also Bonsai-related; Bonsai can link to Bugzilla by matching
> > (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> > http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have this
> > built-in? (haven't looked yet) Is this planned, or has it been discussed
> > and been considered not worth the hassle?
>
> This is planned and I think there are third-party patches for this
> (cannot find them quickly, though), but upstream gitweb does not have
> the support for this included yet.
I'd love to have a link to these patches, honestly. "Our" commit messages are
poor enough that more often than not, the whole commit message is, for
instance, "fix bug #xxxx". While I push hard for more explicit commit
messages, this is just a pipe dream and that link to Bugzilla is vital to
us...
--
fge
^ permalink raw reply
* What's cooking in git.git (Nov 2008, #02; Wed, 05)
From: Junio C Hamano @ 2008-11-06 1:11 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* gb/gitweb-snapshot-pathinfo (Sun Nov 2 10:21:39 2008 +0100) 3 commits
- gitweb: embed snapshot format parameter in PATH_INFO
- gitweb: retrieve snapshot format from PATH_INFO
- gitweb: make the supported snapshot formats array global
Waiting for re-Ack.
* bc/maint-keep-pack (Mon Nov 3 14:43:22 2008 -0600) 3 commits
- pack-objects: honor '.keep' files
- packed_git: convert pack_local flag into a bitfield and add
pack_keep
- t7700: demonstrate mishandling of objects in packs with a .keep
file
* st/tag (Wed Nov 5 00:20:36 2008 +0100) 2 commits
- tag: Add more tests about mixing incompatible modes and options
- tag: Check that options are only allowed in the appropriate mode
Still needs fix not to update unchanged refs.
* np/pack-safer (Wed Oct 29 19:02:52 2008 -0400) 9 commits
- pack-objects: don't leak pack window reference when splitting
packs
- extend test coverage for latest pack corruption resilience
improvements
- pack-objects: allow "fixing" a corrupted pack without a full
repack
- make find_pack_revindex() aware of the nasty world
- make check_object() resilient to pack corruptions
- make packed_object_info() resilient to pack corruptions
- make unpack_object_header() non fatal
- better validation on delta base object offsets
- close another possibility for propagating pack corruption
* mv/remote-rename (Mon Nov 3 19:26:18 2008 +0100) 1 commit
. Implement git remote rename
* lt/decorate (Mon Nov 3 11:25:46 2008 -0800) 4 commits
+ revision traversal: '--simplify-by-decoration'
+ Make '--decorate' set an explicit 'show_decorations' flag
+ revision: make tree comparison functions take commits rather than
trees
+ Add a 'source' decorator for commits
* cb/maint-update-ref-fix (Wed Nov 5 21:55:54 2008 +0100) 2 commits
+ push: fix local refs update if already up-to-date
+ do not force write of packed refs
----------------------------------------------------------------
[Graduated to "master"]
* mv/maint-branch-m-symref (Sat Nov 1 00:25:44 2008 +0100) 5 commits
+ update-ref --no-deref -d: handle the case when the pointed ref is
packed
+ git branch -m: forbid renaming of a symref
+ Fix git update-ref --no-deref -d.
+ rename_ref(): handle the case when the reflog of a ref does not
exist
+ Fix git branch -m for symrefs.
Will merge down to 'maint' in the next round.
* ar/maint-mksnpath (Mon Oct 27 11:22:09 2008 +0100) 7 commits
+ Use git_pathdup instead of xstrdup(git_path(...))
+ git_pathdup: returns xstrdup-ed copy of the formatted path
+ Fix potentially dangerous use of git_path in ref.c
+ Add git_snpath: a .git path formatting routine with output buffer
+ Fix potentially dangerous uses of mkpath and git_path
+ Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
+ Add mksnpath which allows you to specify the output buffer
Will merge down to 'maint' in the next round.
* cj/maint-gitpm-fix-maybe-self (Sat Oct 18 20:25:12 2008 +0200) 1 commit
+ Git.pm: do not break inheritance
Will merge down to 'maint' in the next round.
* gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
+ gitweb: generate parent..current URLs
+ gitweb: parse parent..current syntax from PATH_INFO
+ gitweb: use_pathinfo filenames start with /
+ gitweb: generate project/action/hash URLs
+ gitweb: parse project/action/hash_base:filename PATH_INFO
Seventh iteration.
* ag/blame-encoding (Wed Oct 22 00:55:57 2008 +0400) 1 commit
+ builtin-blame: Reencode commit messages according to git-log
rules.
* mv/parseopt-checkout-index (Sat Oct 18 03:17:23 2008 +0200) 1 commit
+ parse-opt: migrate builtin-checkout-index.
* sh/rebase-i-p (Wed Oct 22 11:59:30 2008 -0700) 9 commits
+ git-rebase--interactive.sh: comparision with == is bashism
+ rebase-i-p: minimum fix to obvious issues
+ rebase-i-p: if todo was reordered use HEAD as the rewritten parent
+ rebase-i-p: do not include non-first-parent commits touching
UPSTREAM
+ rebase-i-p: only list commits that require rewriting in todo
+ rebase-i-p: fix 'no squashing merges' tripping up non-merges
+ rebase-i-p: delay saving current-commit to REWRITTEN if squashing
+ rebase-i-p: use HEAD for updating the ref instead of mapping
OLDHEAD
+ rebase-i-p: test to exclude commits from todo based on its parents
Changes the `rebase -i -p` behavior to behave like git sequencer's
rewrite of `rebase -i` would behave.
* np/index-pack (Thu Oct 23 15:05:59 2008 -0400) 5 commits
+ index-pack: don't leak leaf delta result
+ improve index-pack tests
+ fix multiple issues in index-pack
+ index-pack: smarter memory usage during delta resolution
+ index-pack: rationalize delta resolution code
The buglets that caused people on 'next' some surprises are quickly
killed. Thanks.
* jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
+ Fix reading of cloud tags
Got tired of waiting for an Ack.
----------------------------------------------------------------
[Actively Cooking]
* rs/blame (Sat Oct 25 15:31:36 2008 +0200) 5 commits
+ blame: use xdi_diff_hunks(), get rid of struct patch
+ add xdi_diff_hunks() for callers that only need hunk lengths
+ Allow alternate "low-level" emit function from xdl_diff
+ Always initialize xpparam_t to 0
+ blame: inline get_patch()
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 4 commits
. [WaitForResponse] Add autoconf tests for pthreads
+ Make Pthread link flags configurable
+ Add Makefile check for FreeBSD 4.9-SECURITY
+ Build: add NO_UINTMAX_T to support ancient systems
The topmost one unconditionally enables threaded delta search on any
platform on which Pthread library is detected to be available, which
may not be what we want.
* ds/autoconf (Sun Oct 26 03:52:19 2008 -0800) 1 commit
+ autoconf: Add link tests to each AC_CHECK_FUNC() test
Attempts to help FreeBSD whose compiler does not error out when told to
compile a program that calls unavailable functions.
* jk/diff-convfilter (Sun Oct 26 00:50:02 2008 -0400) 8 commits
+ enable textconv for diff in verbose status/commit
+ wt-status: load diff ui config
+ only textconv regular files
+ userdiff: require explicitly allowing textconv
+ refactor userdiff textconv code
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
* jk/diff-convfilter-test-fix (Fri Oct 31 01:09:13 2008 -0400) 1 commit
+ Avoid using non-portable `echo -n` in tests.
An update to the one above.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
----------------------------------------------------------------
[Stalled]
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Needs review.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
- gitweb: Better processing format string in custom links in navbar
Waiting for some sort of response from Pasky.
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Petr Baudis @ 2008-11-05 23:50 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811060014.57046.fg@one2team.net>
Hi,
On Thu, Nov 06, 2008 at 12:14:56AM +0100, Francis Galiegue wrote:
> * second: even though this may be a "non problem", we use Bonsai, which has
> the ability to see what was commited by whom, given a time interval (from d1
> to d2): the base gitweb allows to search by commiter, which is good, but it
> has no date boundaries: do tools exist for git that can do this? If not, that
> wouldn't be a big deal, however...
git log --since='2 months ago' --until='1 month ago'
There is no gitweb functionality for this right now, but I think an
implementation of that would be welcome in principle.
> * third: also Bonsai-related; Bonsai can link to Bugzilla by matching (wild
> guess) /\b(?:#?)(\d+)\b/ and transforming this into
> http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have this
> built-in? (haven't looked yet) Is this planned, or has it been discussed and
> been considered not worth the hassle?
This is planned and I think there are third-party patches for this
(cannot find them quickly, though), but upstream gitweb does not have
the support for this included yet.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Shawn O. Pearce @ 2008-11-05 23:44 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811060034.48053.fg@one2team.net>
Francis Galiegue <fg@one2team.net> wrote:
> Le Thursday 06 November 2008 00:23:48 Shawn O. Pearce, vous avez écrit :
> > Francis Galiegue <fg@one2team.net> wrote:
> > > Finally, about the Eclipse plugin:
>
> > > * if the plugin can push, can you configure from within the plugin what
> > > branches can be pushed where, or should you edit .git/config by hand?
> >
> > I don't think you can edit saved configurations in the plugin UI.
>
> Not a big deal, I guess. This can be handled... (BTW, what about "git clone"?
> Still not there, although _this_ can be dealt with also)
File->Import... from Git. That can clone a repository. After it
finishes you'll have to use the import wizard again to actually
import existing .project files, or create new projects, etc.
> > > * "git stash": is it supported?
> >
> > Not in Eclipse, no.
>
> What do you mean by this?
I mean there's no implementation of git stash. Eclipse doesn't
support git stash, the notion of the stash, the branch the stash
is on. Its not in the Eclipse plugin.
> > > * can you "copy" a commit, or even a set of commits, and "cherry-pick"
> > > them into another branch? Or even rebase a branch onto antoher?
> >
> > Not in Eclipse, no.
>
> Same question... What exactly is the problem with Eclipse wrt this kind of
> operation?
Its also not implemented in the eclipse UI.
--
Shawn.
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Francis Galiegue @ 2008-11-05 23:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081105232348.GP15463@spearce.org>
Le Thursday 06 November 2008 00:23:48 Shawn O. Pearce, vous avez écrit :
> Francis Galiegue <fg@one2team.net> wrote:
> > Finally, about the Eclipse plugin:
> > * the README says that it has no push capacity, the popup menu says
> > otherwise (last checked last Saturday)... What should I believe?
>
> The README is out of date. Push is implemented, works, and folks
> actually use it. That was a nice success from our GSoC program
> this year.
>
Good to hear :p Any chance that the README gets updated? ;)
> > * if the plugin can push, can you configure from within the plugin what
> > branches can be pushed where, or should you edit .git/config by hand?
>
> I don't think you can edit saved configurations in the plugin UI.
> The APIs are there underneath to do the reading/writing and most
> of the UI to show a configuration is present, I just don't think
> anyone has wired the two together for saved configurations inside
> of .git/config. So yea, edit by hand.
>
Not a big deal, I guess. This can be handled... (BTW, what about "git clone"?
Still not there, although _this_ can be dealt with also)
> > * "git stash": is it supported?
>
> Not in Eclipse, no.
>
What do you mean by this?
> > * can you "copy" a commit, or even a set of commits, and "cherry-pick"
> > them into another branch? Or even rebase a branch onto antoher?
>
> Not in Eclipse, no.
Same question... What exactly is the problem with Eclipse wrt this kind of
operation?
--
fge
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Jakub Narebski @ 2008-11-05 23:26 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <200811060136.23806.angavrilov@gmail.com>
Alexander Gavrilov wrote:
> How about the following patch, that simply adds a hook, and provides
> an example using mod_perl in the documentation?
Very nice, simple yet powerfull solution.
> --- >8 ---
> Subject: [PATCH] gitweb: Add a per-repository authorization hook.
>
> Add a configuration variable that can be used to specify an
> arbitrary subroutine that will be called in the same situations
> where $export_ok is checked, and its return value used
> to decide whether the repository is to be shown.
>
> This allows the user to implement custom authentication
> schemes, for example by issuing a subrequest through mod_perl
> and checking if Apache will authorize it.
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
If somebody could check out example given for this feature, I'd add
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/INSTALL | 21 +++++++++++++++++++++
> gitweb/gitweb.perl | 8 +++++++-
> 2 files changed, 28 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/INSTALL b/gitweb/INSTALL
> index 26967e2..fa5917a 100644
> --- a/gitweb/INSTALL
> +++ b/gitweb/INSTALL
> @@ -166,6 +166,27 @@ Gitweb repositories
> shows repositories only if this file exists in its object database
> (if directory has the magic file named $export_ok).
>
> +- Finally, it is possible to specify an arbitrary perl subroutine that
> + will be called for each project to determine if it can be exported.
> + The subroutine receives an absolute path to the project as its only
> + parameter.
> +
> + For example, if you use mod_perl to run the script, and have dumb
> + http protocol authentication configured for your repositories, you
> + can use the following hook to allow access only if the user is
> + authorized to read the files:
> +
> + $export_auth_hook = sub {
> + use Apache2::SubRequest ();
> + use Apache2::Const -compile => qw(HTTP_OK);
> + my $path = "$_[0]/HEAD";
> + my $r = Apache2::RequestUtil->request;
> + my $sub = $r->lookup_file($path);
> + return $sub->filename eq $path
> + && $sub->status == Apache2::Const::HTTP_OK;
> + };
Can anybody check this? Or was it checked by author?
> +
> +
> Generating projects list using gitweb
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 172ea6b..9329880 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -95,6 +95,11 @@ our $default_projects_order = "project";
> # (only effective if this variable evaluates to true)
> our $export_ok = "++GITWEB_EXPORT_OK++";
>
> +# show repository only if this subroutine returns true
> +# when given the path to the project, for example:
> +# sub { return -e "$_[0]/git-daemon-export-ok"; }
> +our $export_auth_hook = undef;
> +
Simple, yet powerfull. Nice short example.
> # only allow viewing of repositories also shown on the overview page
> our $strict_export = "++GITWEB_STRICT_EXPORT++";
>
> @@ -400,7 +405,8 @@ sub check_head_link {
> sub check_export_ok {
> my ($dir) = @_;
> return (check_head_link($dir) &&
> - (!$export_ok || -e "$dir/$export_ok"));
> + (!$export_ok || -e "$dir/$export_ok") &&
> + (!$export_auth_hook || $export_auth_hook->($dir)));
Nice.
> }
>
> # process alternate names for backward compatibility
> --
> tg: (0d4f9de..) t/authenticate/hook (depends on: t/authenticate/unify-exportok)
>
P.S. Why doesn't TopGit add git and TopGit version to signature?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Shawn O. Pearce @ 2008-11-05 23:23 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811060014.57046.fg@one2team.net>
Francis Galiegue <fg@one2team.net> wrote:
> Finally, about the Eclipse plugin:
> * the README says that it has no push capacity, the popup menu says otherwise
> (last checked last Saturday)... What should I believe?
The README is out of date. Push is implemented, works, and folks
actually use it. That was a nice success from our GSoC program
this year.
> * if the plugin can push, can you configure from within the plugin what
> branches can be pushed where, or should you edit .git/config by hand?
I don't think you can edit saved configurations in the plugin UI.
The APIs are there underneath to do the reading/writing and most
of the UI to show a configuration is present, I just don't think
anyone has wired the two together for saved configurations inside
of .git/config. So yea, edit by hand.
> * "git stash": is it supported?
Not in Eclipse, no.
> * can you "copy" a commit, or even a set of commits, and "cherry-pick" them
> into another branch? Or even rebase a branch onto antoher?
Not in Eclipse, no.
--
Shawn.
^ permalink raw reply
* Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Francis Galiegue @ 2008-11-05 23:14 UTC (permalink / raw)
To: git
Hello list,
Since my first email where I said that we wanted to migrate from CVS to a
distributed SCM, we have had a lot of discussions with developers and my
chief (which happens to be a developer too). We have come to the following
conclusions:
* git has credentials (heck, it "runs" the Linux kernel, Wine, Samba, and
other);
* the "distributed" part of it is indeed an advantage (planned developments
with huge technical/functional impacts);
* 52 CVS modules, fine; but then this can become one and 52 subdirectories in
them and still act as separate modules from the build system point of view
(which I have implemented, so I can change it);
* we have enough resources that the old CVS tree can be kept, even on tape,
the day we decide to "scrap it all" and start anew;
* CVS "good practices" have barely been observed, so "we" might as well start
again from a sane base.
So, git looks like a great solution. The Eclipse plugin evolves nicely, you
still can decide on a "central" repository... Looks good.
There are, however, a few problems:
* first: I am not an Eclipse user, and the two main developers use Eclipse
extensively (but even they are lost because of CVS, which is to "my"
advantage), so some questions below will focus on the Eclipse plugin;
* second: even though this may be a "non problem", we use Bonsai, which has
the ability to see what was commited by whom, given a time interval (from d1
to d2): the base gitweb allows to search by commiter, which is good, but it
has no date boundaries: do tools exist for git that can do this? If not, that
wouldn't be a big deal, however...
* third: also Bonsai-related; Bonsai can link to Bugzilla by matching (wild
guess) /\b(?:#?)(\d+)\b/ and transforming this into
http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have this
built-in? (haven't looked yet) Is this planned, or has it been discussed and
been considered not worth the hassle?
Finally, about the Eclipse plugin:
* the README says that it has no push capacity, the popup menu says otherwise
(last checked last Saturday)... What should I believe?
* if the plugin can push, can you configure from within the plugin what
branches can be pushed where, or should you edit .git/config by hand?
* "git stash": is it supported?
* can you "copy" a commit, or even a set of commits, and "cherry-pick" them
into another branch? Or even rebase a branch onto antoher?
Thanks,
--
fge
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Dmitry Potapov @ 2008-11-05 22:53 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Jeff King, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <1225822231.6722.3.camel@maia.lan>
On Wed, Nov 05, 2008 at 07:10:31AM +1300, Sam Vilain wrote:
> On Tue, 2008-11-04 at 12:18 +0300, Dmitry Potapov wrote:
> > > I can see that some people want this behaviour by default; but to me
> > > "push the current branch back to where it came from" seems like far more
> > > a rational default for at least 90% of users.
> >
> > I think it depends on one's workflow. If you use a centralized workflow
> > as with CVS then yes, 90% cases you want to push the current branch. On
> > the other hand, if people push their changes to the server only for
> > review, it means that accidentally pushing more than one intended is not
> > a big deal.
>
> Perhaps not, but it was still unintended.
Even if it were unintended, it will be noticed and corrected immediately,
while forgetting to push some changes is not so obvious... Anyway, your
workflow assumes that one wants to push changes immediately before
switching to another branch, while there are many people who do that
later (after some additional testing or just at the end of their workday).
> I really can't understand the
> opposition to making this command make many people less angry at it.
Because it breaks how this command works now. So I don't think it is a
good idea to make some people less angry while enraging many others over
breaking their workflow. Compatibility should not be taken lightly.
Dmitry
^ permalink raw reply
* Re: [PATCH] push: fix local refs update if already up-to-date
From: Jeff King @ 2008-11-05 22:44 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20081105202849.GA9484@localhost>
On Wed, Nov 05, 2008 at 09:28:49PM +0100, Clemens Buchacher wrote:
> The reason it doesn't work is a bug in lock_ref_sha1_basic(). Dating back to
> pre-"pack-refs" times, this code forces a write if the ref file does not
> exist. I will resubmit the patch including your above testcase and a bugfix
> for lock_ref_sha1_basic().
OK, thanks for looking into it further. Both patches look sane to me.
-Peff
^ 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