* [StGit PATCH] stgit.el: Try to make the point stay on the coalesced patch.
From: David Kågedal @ 2008-11-06 10:27 UTC (permalink / raw)
To: kha, catalin.marinas; +Cc: git
It might not be spot on if all the coalesced patches were unapplied.
---
This fixes a small annoyance with the 'c' command.
contrib/stgit.el | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index d0f19c3..971ecd1 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -193,6 +193,9 @@ Commands:
(let ((patchsym (intern patch)))
(setq stgit-marked-patches (delq patchsym stgit-marked-patches))))
+(defun stgit-clear-marks ()
+ (setq stgit-marked-patches '()))
+
(defun stgit-marked-patches ()
"Return the names of the marked patches."
(mapcar 'symbol-name stgit-marked-patches))
@@ -406,8 +409,15 @@ With numeric prefix argument, pop that many patches."
(write-region (point-min) (point-max) file)
(stgit-capture-output nil
(apply 'stgit-run "coalesce" "-f" file stgit-patches))
+ (stgit-clear-marks)
(with-current-buffer log-edit-parent-buffer
- (stgit-refresh))))
+ ;; Go to first marked patch and stay there
+ (goto-char (point-min))
+ (re-search-forward (concat "^[>+-]\\*") nil t)
+ (move-to-column goal-column)
+ (let ((pos (point)))
+ (stgit-refresh)
+ (goto-char pos)))))
(defun stgit-help ()
"Display help for the StGit mode."
^ permalink raw reply related
* Re: How to rebase for git svn?
From: Björn Steinbrink @ 2008-11-06 10:24 UTC (permalink / raw)
To: sverre; +Cc: Eric Wong, Yang Zhang, git
In-Reply-To: <bd6139dc0811060215j1ad7ee0ahd0b568283da06cb@mail.gmail.com>
On 2008.11.06 11:15:21 +0100, Sverre Rabbelier wrote:
> On Thu, Nov 6, 2008 at 10:55, Eric Wong <normalperson@yhbt.net> wrote:
> > Yang Zhang <yanghatespam@gmail.com> wrote:
> >> Thanks in advance for any help!
> >
> > Try passing --rebase or --squash with "git pull" to keep history linear
> > for SVN.
>
> Consider doing the following:
> git config alias.repull "pull --rebase"
> And then using 'git repull' instead of 'git pull'.
Or set branch.<name>.rebase in your config and just use "git pull" ;-)
Setting branch.autosetuprebase might also be useful in that case.
You should be careful to make sure that the other side does not lag
behind WRT svn, though. Otherwise, you end up rebasing commits that
corresponds to svn revisions. Bad.
Björn
^ permalink raw reply
* StGit: stgit mail configuration options
From: David Kågedal @ 2008-11-06 10:21 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
The "stg mail" command uses a couple of configuration options that are
completely undocumented, and don't fit well together.
"stgit.autobcc" seems to give a default value for the --bcc option.
"stgit.mail.prefix seems to give a default value for the --prefix
option.
Shouldn't these both be stgit.* or stgit.mail.*? And shouldn't they be
documented? Or maybe removed?
And I propse that the autobcc option should be a boolean which means
that user.email should be used.
--
David Kågedal
^ permalink raw reply
* Re: How to rebase for git svn?
From: Sverre Rabbelier @ 2008-11-06 10:15 UTC (permalink / raw)
To: Eric Wong; +Cc: Yang Zhang, git
In-Reply-To: <20081106095500.GA9587@untitled>
On Thu, Nov 6, 2008 at 10:55, Eric Wong <normalperson@yhbt.net> wrote:
> Yang Zhang <yanghatespam@gmail.com> wrote:
>> Thanks in advance for any help!
>
> Try passing --rebase or --squash with "git pull" to keep history linear
> for SVN.
Consider doing the following:
git config alias.repull "pull --rebase"
And then using 'git repull' instead of 'git pull'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: How to rebase for git svn?
From: Eric Wong @ 2008-11-06 9:55 UTC (permalink / raw)
To: Yang Zhang; +Cc: git
In-Reply-To: <4911EF4C.8030703@gmail.com>
Yang Zhang <yanghatespam@gmail.com> wrote:
> Hi, I made a git svn repository from an svn repository. Then I cloned
> the git repository, committed some changes to the clone, and pulled back
> to the original repository. However, now the original repository gives
> me conflicts whenever I run git svn rebase. I believe this is because
> git pull treats the other repository's commits as a branch and merges
> them back instead of rebasing them and maintaining the type of linear
> history that is good for playing with svn. Any hints as to how to fix
> this? I think the solution is to undo the merge that resulted from the
> pull, but I don't know how to do this.
>
> I wrote a simple script reproducing exactly what's going on (along with
> a transcript of its output). I tried to make it as simple as possible,
> but it can probably be simplified even more to reproduce the problem:
>
> http://assorted.svn.sourceforge.net/viewvc/assorted/sandbox/trunk/src/git/gitsvn.bash?revision=1057&view=markup
>
> Thanks in advance for any help!
Hi,
Try passing --rebase or --squash with "git pull" to keep history linear
for SVN.
--
Eric Wong
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Björn Steinbrink @ 2008-11-06 9:51 UTC (permalink / raw)
To: Deskin Miller; +Cc: Miles Bader, git
In-Reply-To: <20081106032437.GA27237@euler>
On 2008.11.05 22:24:37 -0500, Deskin Miller wrote:
> 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
That should be A^ ;-)
> newbranch will have <...> --D--A--B--C
... and then you can merge newbranch into the existing branch that
references D, fast-forwarding the branch. And then newbranch can be
deleted.
If you don't want to use a temporary branch, you can also do (while on
the branch onto which you want to cherry-pick):
git reset --hard C
git rebase --onto ORIG_HEAD A^
Which should get you the same result, without using a temporary branch.
Björn
^ permalink raw reply
* Re: [PATCH v2] git-svn: proper detection of bare repositories
From: Eric Wong @ 2008-11-06 9:45 UTC (permalink / raw)
To: Deskin Miller; +Cc: git, gitster
In-Reply-To: <20081106050739.GA7713@euler>
Deskin Miller <deskinm@umich.edu> wrote:
> 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.
Thanks, acked and pushed out to git://git.bogomips.org/git-svn.git
--
Eric Wong
^ permalink raw reply
* 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
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