* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-06 15:43 UTC (permalink / raw)
To: Jeremy O'Brien; +Cc: miles, Johannes.Schindelin, git
In-Reply-To: <49b12ff7.nCWIz4ABJcgwW3BZ%obrien654j@gmail.com>
On Fri, Mar 6, 2009 at 9:15 AM, Jeremy O'Brien <obrien654j@gmail.com> wrote:
> Miles Bader <miles@gnu.org> wrote:
>
>> Alternatively, maybe a "git track [REMOTE [BRANCH]]" command that simply
>> adds makes adding the appropriate config magic more convenient ?
>>
>> I dunno what the arg syntax would look like in the general case;
>> I almost always want to use the current branch, and track an identically
>> named branch in the origin remote though...
I don't think we need a new command, but it would probably fit into git remote
$ git remote track <remote> [<branch>]
j.
^ permalink raw reply
* Re: [PATCH] [JGit] Fix parsing peeled line in packed-ref
From: Shawn O. Pearce @ 2009-03-06 15:43 UTC (permalink / raw)
To: Daniel Cheng (aka SDiZ); +Cc: git, Daniel Cheng (aka SDiZ)
In-Reply-To: <1236353138-1427-1-git-send-email-j16sdiz+freenet@sdiz.net>
"Daniel Cheng (aka SDiZ)" <j16sdiz+freenet@gmail.com> wrote:
> When doing a WalkTransport with packed-ref, peeled
> line are not handled correctly. This patch fix the
> issue.
Wow. That old code was really wrong. :-)
Signed-off-by? (See SUBMITTING_PATCHES, "(5) Sign your work")
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
> index a4f8961..d8e727b 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
> @@ -436,7 +436,7 @@ private void readPackedRefsImpl(final Map<String, Ref> avail,
> if (line.charAt(0) == '^') {
> if (last == null)
> throw new TransportException("Peeled line before ref.");
> - final ObjectId id = ObjectId.fromString(line + 1);
> + final ObjectId id = ObjectId.fromString(line.substring(1));
> last = new Ref(Ref.Storage.PACKED, last.getName(), last
If I'm at fault for that preimage, I should just be put out to
pasture now... before I do any more harm... *sigh*
--
Shawn.
^ permalink raw reply
* Re: import files w/ history
From: Miklos Vajna @ 2009-03-06 15:33 UTC (permalink / raw)
To: Csaba Henk; +Cc: git
In-Reply-To: <slrngr299k.1t4t.csaba-ml@beastie.creo.hu>
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
On Fri, Mar 06, 2009 at 01:29:38PM +0000, Csaba Henk <csaba-ml@creo.hu> wrote:
> $ git filter-branch --commit-filter '
> if [ $# -lt 3 ] || git diff --stat $3 $1 | grep -q 'sys/dev/disk/vn/vn\.c'
> then
> git commit-tree "$@"
> else
> skip_commit "$@"
> fi' HEAD
Did you notice --subdirectory-filter? Maybe it would be more efficient
to run --subdirectory-filter sys/dev/disk/vn first, then you can play
with the resulting small repo to suit your needs. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Using Git with windows
From: Dmitry Potapov @ 2009-03-06 15:30 UTC (permalink / raw)
To: Tim Visher; +Cc: Tariq Hassanen, git
In-Reply-To: <c115fd3c0903060638lfc52073nd40e0d7379d7f593@mail.gmail.com>
On Fri, Mar 6, 2009 at 5:38 PM, Tim Visher <tim.visher@gmail.com> wrote:
>
> IMHO, Git under cygwin's pretty nice. I tried using MSysGit as well
> and didn't feel like it was quite as good as just building Git under
> cygwin. I also run Git on an Mac at home and while it's clearly
> faster, Git under Cygwin still beats the pants off of SVN under
> Cygwin.
If I am not mistaken Git 1.6.1 should work about twice faster under
Cygwin than previous versions with such common operations as
"git diff", "git status", because it avoids emulation of stat() in most
common cases...
>
>> But is there a way around this if i run a linux VM with Git running
>> and mount a windows ntfs partition ?
>
> Would this really be faster? I don't have a whole lot of experience
> with virtualization, but isn't Cygwin 'basically' doing this already?
No, Cygwin works very differently... In some cases, Cygwin will work
faster, but there are operations that are very costly under Cygwin
such as fork(). So, what is faster depends on what you do, and
there are many other factors here such available memory or
present some antivirus programs, which can kill performance...
But, in general, if you work on Windows, it makes much more
sense to Cygwin or MSysGit than running Git under VmWare...
Dmitry
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Jakub Narebski @ 2009-03-06 15:27 UTC (permalink / raw)
To: John Tapsell
Cc: Finn Arne Gangstad, Junio C Hamano, Johannes Schindelin,
Sverre Rabbelier, markus.heidelberg, git, Andreas Ericsson
In-Reply-To: <43d8ce650903060426y776474fi10acc5495b88fa7@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> 2009/3/6 Finn Arne Gangstad <finnag@pvv.org>:
>> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>
>>>> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>>>>
>>>>> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
>>>>> <markus.heidelberg@web.de> wrote:
>>>>>> Oh, I confused "config option" with "command line argument"...
>>>>>
>>>>> Right, I'd like to be able to do:
>>>>> $ git config push.iamnotretarded true
>>>>> $ git push
>>>>
>>>> LOL! Sverre, you have a way to crack me up...
>>>
>>> I found it amusing, too.
>>>
>>> It may have some correlation with how well organized your work habit is,
>>> but I do not think it has much correlation with being retarded. It is
>>> more about "'matching refs' is the perfect default for _my_ use pattern,
>>> don't mess with it, please".
>>
>> So here is my current WIP suggestion for a new "push.default"
>> variable, I am not sure if a single entry can express all useful
>> choices, or if it is a good idea to introduce more default choices
>> other than "nothing" (with the goal of making it the default in a
>> later release).
>>
>> I think all the values here make sense as a --option to git push
>> though (except --nothing...)
>>
>> Suggested new entry in config.txt:
>>
>> push.default::
>> Defines the action git push should take if no refspec is given
>> on the command line, no refspec is configured in the branch, and
>> no refspec is implied by any of the options given on the command
>> line.
>> +
>> The term `current remote` means the remote configured for the current
>> branch, or `origin` if no remote is set. `origin` is also used if
>> you are not on a branch at all.
>> +
>> * `nothing` do not push anything
>> * `matching` push all matching branches to the current remote.
>> All branches having the same name in both ends are considered to be
>> matching. This is the default value.
>> * `same-remote` push all matching branches that are configured to use
>> the current remote. Branches with no remote configuration are not pushed.
>> * `tracked` push all branches that are tracking a branch on the current
>> remote to their counterpart.
>
> How about 'current', to simply push the current the branch. It could
> even prompt if it's not tracked yet.
Note that if you have configuration for <remote>, you can simply add
"remote.<remote>.push = HEAD" for pushing current branch only, and
"remote.<remote>.push = :" for current matching behavior. Perhaps
"remote.<remote>.push = " works for push nothing?
> Most (all?) other revision control systems have this 'current'
> behaviour by default.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] [JGit] Fix parsing peeled line in packed-ref
From: Daniel Cheng (aka SDiZ) @ 2009-03-06 15:26 UTC (permalink / raw)
To: git; +Cc: Daniel Cheng (aka SDiZ)
From: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@sdiz.net>
When doing a WalkTransport with packed-ref, peeled
line are not handled correctly. This patch fix the
issue.
---
.../jgit/transport/WalkRemoteObjectDatabase.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
index a4f8961..d8e727b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
@@ -436,7 +436,7 @@ private void readPackedRefsImpl(final Map<String, Ref> avail,
if (line.charAt(0) == '^') {
if (last == null)
throw new TransportException("Peeled line before ref.");
- final ObjectId id = ObjectId.fromString(line + 1);
+ final ObjectId id = ObjectId.fromString(line.substring(1));
last = new Ref(Ref.Storage.PACKED, last.getName(), last
.getObjectId(), id, true);
avail.put(last.getName(), last);
--
1.6.2.rc2
^ permalink raw reply related
* [PATCH] [JGit] Fix parsing peeled line in packed-ref
From: Daniel Cheng (aka SDiZ) @ 2009-03-06 15:25 UTC (permalink / raw)
To: git; +Cc: Daniel Cheng (aka SDiZ)
When doing a WalkTransport with packed-ref, peeled
line are not handled correctly. This patch fix the
issue.
---
.../jgit/transport/WalkRemoteObjectDatabase.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
index a4f8961..d8e727b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
@@ -436,7 +436,7 @@ private void readPackedRefsImpl(final Map<String, Ref> avail,
if (line.charAt(0) == '^') {
if (last == null)
throw new TransportException("Peeled line before ref.");
- final ObjectId id = ObjectId.fromString(line + 1);
+ final ObjectId id = ObjectId.fromString(line.substring(1));
last = new Ref(Ref.Storage.PACKED, last.getName(), last
.getObjectId(), id, true);
avail.put(last.getName(), last);
--
1.6.2.rc2
^ permalink raw reply related
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Jakub Narebski @ 2009-03-06 15:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Finn Arne Gangstad, Junio C Hamano, Sverre Rabbelier,
markus.heidelberg, git, John Tapsell, Andreas Ericsson
In-Reply-To: <alpine.DEB.1.00.0903061306450.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 6 Mar 2009, Finn Arne Gangstad wrote:
>> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>>>>>
>>>>> Right, I'd like to be able to do:
>>>>> $ git config push.iamnotretarded true
>>>>> $ git push
>>>>
>>>> LOL! Sverre, you have a way to crack me up...
>>>
>>> I found it amusing, too.
>>>
>>> It may have some correlation with how well organized your work habit is,
>>> but I do not think it has much correlation with being retarded. It is
>>> more about "'matching refs' is the perfect default for _my_ use pattern,
>>> don't mess with it, please".
>>
>> So here is my current WIP suggestion for a new "push.default"
>> variable, I am not sure if a single entry can express all useful
>> choices, or if it is a good idea to introduce more default choices
>> other than "nothing" (with the goal of making it the default in a
>> later release).
>
> Speaking of which, Steffen (who cannot reply right now, since he is AFK
> for a while) had a patch to install "remote.<branch>.push = HEAD" with
> clone and remote. Would that be better?
Errr... I thought that "remote.<remotename>.push = HEAD" works?
But note that "remote.<name>.push = HEAD" (push current branch only)
and "remote.<name>.push = :" (push matching branches, i.e. curent
behavior) works only if you have remote configured... "git push <URL>"
won't be affected, and people (probably) would want to either have
'nothing' as default, or/and be able to configure it to nothing,
current, or matching (at least).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] TortoiseGit 0.4.1.0 release
From: Eric Hanchrow @ 2009-03-06 15:13 UTC (permalink / raw)
To: John Dlugosz; +Cc: git, lznuaa
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F07D26@EXCHANGE.trad.tradestation.com>
On Thu, Mar 5, 2009 at 12:02 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:
>>> TortoiseGit 0.3.3 released.
>
> I just downloaded the 64-bit version, and can't get it to come up.
Ditto with the 32-bit version: it appeared to install OK, but after
rebooting, I have no new entries on my context menus.
^ permalink raw reply
* marking (cherry-pick) commits ?
From: Marc Weber @ 2009-03-06 14:41 UTC (permalink / raw)
To: Git Mailing List
I've this situation:
base --------- branch_A (svn trunk)
` ---------- branch_B (svn branch )
Some cherry picks have been done both dirctions.
Is there a way show gitk branch_A branch_B and mark cherry-picks?
I only know about --left-right --cherry-pick and such omitting them.
How does --cherry-pick work? Is it based on git-commit-id?
Probably it would be enough to write a simple script iterating over both
brnaches adding some temporary tags pointing out the pairs of
cherry-picked patches..
Is there another way "marking" patches?
Maybe it would be fun to use
git tab tmp_dont_commit_red_message
git tab tmp_dont_commit_green_message
and ask gitk to show them in red and green?
Can I tell git push to not push all tags starting with tmp_dont_commit_
?
There are only about 120 patches.. So I can manually handle that case..
But I guess git can do better.
Sincerly
Marc Weber
^ permalink raw reply
* Re: Using Git with windows
From: Tim Visher @ 2009-03-06 14:38 UTC (permalink / raw)
To: Tariq Hassanen; +Cc: git
In-Reply-To: <e878dbad0903052323m56f3d63fi69862e9dae278c00@mail.gmail.com>
On Fri, Mar 6, 2009 at 2:23 AM, Tariq Hassanen <tariq.hassanen@gmail.com> wrote:
> I know there are some ports for it on windows such as msysGit and it
> can also be done on Cygwin.
IMHO, Git under cygwin's pretty nice. I tried using MSysGit as well
and didn't feel like it was quite as good as just building Git under
cygwin. I also run Git on an Mac at home and while it's clearly
faster, Git under Cygwin still beats the pants off of SVN under
Cygwin.
> But is there a way around this if i run a linux VM with Git running
> and mount a windows ntfs partition ?
Would this really be faster? I don't have a whole lot of experience
with virtualization, but isn't Cygwin 'basically' doing this already?
I mean, it's attempting to emulate linux system calls so that linux
software can be recompiled to run on o a Windows box.
> Any ideas? Or am i best sticking with SVN until the ports are mature enough?
> Tariq
I wouldn't bother waiting. Git is plenty mature on Windows, either
via msys or via Cygwin. There's no real reason to delay. :)
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: ignored files stilll listed in git ls-files
From: Jeff King @ 2009-03-06 14:31 UTC (permalink / raw)
To: David Shen; +Cc: git
In-Reply-To: <53e35fd50903060602n2573217evcd48fdf822adf972@mail.gmail.com>
On Fri, Mar 06, 2009 at 10:02:03PM +0800, David Shen wrote:
> But my problem is only solved on Linux. On my winodws machine, I have
> added a lot of unwanted file to my git repo, before creating
> .gitignore file. I ran 'git rm --cached myfile' to remove it from the
> index. But they still exist in 'git ls-files', because they exist in
> the history. On Linux, I can use 'git filter-branch' to remove them
> from history. But, on windows,
I think filter-branch runs under cygwin (I think it might even run on
msysgit, but just hasn't been included in a shipped version yet). You
can also filter-branch on Linux and then fetch or clone the result to
Windows.
-Peff
^ permalink raw reply
* Re: setting up tracking on push
From: Jeremy O'Brien @ 2009-03-06 14:15 UTC (permalink / raw)
To: miles, Johannes.Schindelin; +Cc: jaysoffian, git
In-Reply-To: <buoy6vi297q.fsf@dhlpc061.dev.necel.com>
Miles Bader <miles@gnu.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> > I vaguely feel like I should be able to do:
> >> >
> >> > git push --track origin grognul
> >
> > http://search.gmane.org/?query=push+track&group=gmane.comp.version-control.git
> >
> > Summary for the lazy: it needs a lot of work to be implemented properly.
>
> Alternatively, maybe a "git track [REMOTE [BRANCH]]" command that simply
> adds makes adding the appropriate config magic more convenient ?
>
> I dunno what the arg syntax would look like in the general case;
> I almost always want to use the current branch, and track an identically
> named branch in the origin remote though...
>
> -Miles
I definitely second this approach. It would be very useful.
^ permalink raw reply
* Re: ignored files stilll listed in git ls-files
From: David Shen @ 2009-03-06 14:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090305090953.GB30445@coredump.intra.peff.net>
Thanks for replying.
My command was not correct. And I solved my problem with the help from
someone else.
But my problem is only solved on Linux. On my winodws machine, I have
added a lot of unwanted file to my git repo, before creating
.gitignore file. I ran 'git rm --cached myfile' to remove it from the
index. But they still exist in 'git ls-files', because they exist in
the history. On Linux, I can use 'git filter-branch' to remove them
from history. But, on windows,
On Thu, Mar 5, 2009 at 5:09 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Mar 05, 2009 at 09:31:55AM +0800, David Shen wrote:
>
>> I add all the files to git before I learned the .gitignore file. Then
>> I remove those unwanted files from the index. But those files still
>> appear in git ls-files. This is really annoying. Is there any want to
>> prevent those ignored files from git ls-files?
>
> If they are appearing in "git ls-files", then you didn't actually remove
> them from the index. Can you show us exactly which commands you ran,
> what output they produced, and how it differs from what you expected?
>
> -Peff
>
--
Best Regards,
David Shen
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Finn Arne Gangstad @ 2009-03-06 13:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Sverre Rabbelier, markus.heidelberg, git,
John Tapsell, Andreas Ericsson
In-Reply-To: <alpine.DEB.1.00.0903061306450.10279@pacific.mpi-cbg.de>
On Fri, Mar 06, 2009 at 01:07:56PM +0100, Johannes Schindelin wrote:
> [...]
>
> Speaking of which, Steffen (who cannot reply right now, since he is AFK
> for a while) had a patch to install "remote.<branch>.push = HEAD" with
> clone and remote. Would that be better?
Are you referring to the patch he suggested in October 2007? I'm
reading the October/November archives now, and it seems these things
have been discussed before... Ok so re-reading the discussion from
October/November 2007, it seems that we are having exactly the same
discussion again! I did not investigate far enough back in time before
firing up this thread again evidently.
Reading the threads almost makes me sad. Steffen had a lot of great
patches and ideas (implementing --current, adding tests, ...), but it
was somehow dropped. After having read through this it would feel
wrong somehow to even post patches on this topic, since I would
effectively just redo what he already did.
The only difference between his approach and what I am suggesting
seems to be that he mostly wanted "git push" to do various useful
tasks depending on configuration (the remote.<branch>.push stuff),
while I mostly want "git push" to do nothing by default. We both agree
that the current "git push" default behavior is very bad for our
workflow (many developers against one or more shared repos).
- Finn Arne
^ permalink raw reply
* Re: asciidoc, was Re: Chicken/egg problem building from a 'git clone'
From: John Tapsell @ 2009-03-06 13:39 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Jeff King, Matthieu Moy, Git Mailing List
In-Reply-To: <200903061415.50746.jnareb@gmail.com>
2009/3/6 Jakub Narebski <jnareb@gmail.com>:
> On Fri, 6 March 2009, John Tapsell wrote:
>> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>> On Fri, 6 Mar 2009, John Tapsell wrote:
>>>> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>>>> On Fri, 6 Mar 2009, Jakub Narebski wrote:
>
>>>>>> However while toolchain needed to produce documentation (asciidoc +
>>>>>> xmlto) isn't, I think, something very common, in my opinion autoconf is
>>>>>> something that is present on systems containing other build tools
>>>>>> required to build git from sources. So 'configure' branch is not, I
>>>>>> think, as necessary as 'html' and 'man' branches; additionally 'html'
>>>>>> branch (or the repository used to build documentation, or the byproduct
>>>>>> of building documentation) is used to generate on-line docs for git.
>>>>>
>>>>> Plus, keep in mind that autoconf support is only an afterthought in Git;
>>>>> Just running "make" is supposed to work. If it does not, patches are
>>>>> certainly welcome, I think.
>>>>
>>>> Well now that you mention it.. :-)
>>>>
>>>> It doesn't check for the existance of asciidoc, but blindly assumes it
>>>> exists. And even if you do have asciidoc, there's a good chance that
>>>> you have the wrong version. The INSTALL file says that asciidoc
>>>> requires 8.2.7 but most distros (debian, ubuntu. probably other) have
>>>> 8.2.6.
>
> Do you mean here Makefile checks, or do you mean ./configure checking
> for existing asciidoc toolchain, and for asciidoc version?
Well presumably both would have to check, since you can run make
without configure. I just figured starting with configure would be
easiest.
>
>>>> If you compile the docs with the wrong asciidoc version, there is no
>>>> warning or error at all. It just builds incorrect man pages.
>>>
>>> Frankly, I was talking about "make". I never needed asciidoc there.
>>>
>>> Besides, if it is really an itch of yours, maybe you can come up with a
>>> patch checking for a correct asciidoc version? Only if asciidoc would be
>>> needed at all, of course.
>>
>> Yep. I've been looking at it for the last half hour, but configure.ac
>> syntax defeats me :-D (I figured getting the check into configure.ac
>> would be a good first start)
>
> Errr... doesn't configure.ac have checking for asciidoc version? Search
> for AC_CHECK_PROGS(ASCIIDOC, [asciidoc]). Perhaps tests should be more
> detailed, or something...
Yeah I saw that - it checks if you have version 7.* or 8.*. I just
don't know how to check if the version is >= .8.2.7.
John
^ permalink raw reply
* Re: import files w/ history
From: Csaba Henk @ 2009-03-06 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <20090303130046.GA7867@coredump.intra.peff.net>
On 2009-03-03, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 03, 2009 at 12:54:54PM +0000, Csaba Henk wrote:
>
>> How could I import some files from an unrelated git repo with history?
>
> Just "git pull" from the other repo, which will include all of its
> history. If you want to pretend that the other history contains just a
> subset of the true history, use "git filter-branch" to rewrite it first.
Thanks Jeff, but it didn't work well for a large repo. At least not what
I could carve out myself.
The repo in question is the DragonFlyBSD repository, and I wanted to
cut out the history of sys/dev/disk/vn/vn.c. After reading
git-filter-branch(1) I come up with the following: first I wanted to
select those commits where the file in question was modified. I tried
to use the following filtration:
$ git filter-branch --commit-filter '
if [ $# -lt 3 ] || git diff --stat $3 $1 | grep -q 'sys/dev/disk/vn/vn\.c'
then
git commit-tree "$@"
else
skip_commit "$@"
fi' HEAD
It should select those commits where vn.c differs from the vn.c in the _first_
parent, so probably it's not exactly what I want, but anyway, I went on
to give it a try.
I have even tested this filter script on a small repo and it worked
well. Then I ran it against the Dfly repo, and after 23 hours of
processing I ended up with:
...
23575b3e0b087120b0475ae93c505c72a9779fdb
35ac2f0aa5ac0ca78109781817c524fa354e8691
23575b3e0b087120b0475ae93c505c72a9779fdb
35ac2f0aa5ac0ca78109781817c524fa354e8691
23575b3e0b087120b0475ae93c505c72a9779fdb
35ac2f0aa5ac0ca78109781817c524fa354e8691
23575b3e0b087120b0475ae93c505c72a9779fdb
35ac2f0aa5ac0ca78109781817c524fa354e8691
23575b3e0b087120b0475ae93c505c72a9779fdb
35ac2f0aa5ac0ca78109781817c524fa354e8691
WARNING: Ref 'refs/heads/__rewrite' points to the first one now.
And the result is completely f*cked up.
Neither those two commits which occur repeatedly at the end of the
output, nor the commit at the actual position of the __rewrite brach
has a parent, and the upstream commits from which these were derived
didn't affect vn.c.
* * *
OK, I then tried to do more RTFM and be more clever and efficient, and
find a way to specify directly those commits which affect vn.c. As "git
rev-list" can be invoked like "git rev-list <commit> <path>", and the
synopsis of "git filter-branch" is like
git filter-branch [options] [--] [<rev-list options>...]
I then gave a try to:
$ git filter-branch -- master sys/dev/disk/vn/vn.c
but no dice -- I got:
fatal: ambiguous argument 'sys/dev/disk/vn/vn.c': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions
Could not get the commits
Any idea?
Thanks,
Csaba
^ permalink raw reply
* Re: asciidoc, was Re: Chicken/egg problem building from a 'git clone'
From: Jakub Narebski @ 2009-03-06 13:15 UTC (permalink / raw)
To: John Tapsell
Cc: Johannes Schindelin, Jeff King, Matthieu Moy, Git Mailing List
In-Reply-To: <43d8ce650903060428h26392348i4e0db5c23ca57da6@mail.gmail.com>
On Fri, 6 March 2009, John Tapsell wrote:
> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> On Fri, 6 Mar 2009, John Tapsell wrote:
>>> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>>> On Fri, 6 Mar 2009, Jakub Narebski wrote:
>>>>> However while toolchain needed to produce documentation (asciidoc +
>>>>> xmlto) isn't, I think, something very common, in my opinion autoconf is
>>>>> something that is present on systems containing other build tools
>>>>> required to build git from sources. So 'configure' branch is not, I
>>>>> think, as necessary as 'html' and 'man' branches; additionally 'html'
>>>>> branch (or the repository used to build documentation, or the byproduct
>>>>> of building documentation) is used to generate on-line docs for git.
>>>>
>>>> Plus, keep in mind that autoconf support is only an afterthought in Git;
>>>> Just running "make" is supposed to work. If it does not, patches are
>>>> certainly welcome, I think.
>>>
>>> Well now that you mention it.. :-)
>>>
>>> It doesn't check for the existance of asciidoc, but blindly assumes it
>>> exists. And even if you do have asciidoc, there's a good chance that
>>> you have the wrong version. The INSTALL file says that asciidoc
>>> requires 8.2.7 but most distros (debian, ubuntu. probably other) have
>>> 8.2.6.
Do you mean here Makefile checks, or do you mean ./configure checking
for existing asciidoc toolchain, and for asciidoc version?
>>> If you compile the docs with the wrong asciidoc version, there is no
>>> warning or error at all. It just builds incorrect man pages.
>>
>> Frankly, I was talking about "make". I never needed asciidoc there.
>>
>> Besides, if it is really an itch of yours, maybe you can come up with a
>> patch checking for a correct asciidoc version? Only if asciidoc would be
>> needed at all, of course.
>
> Yep. I've been looking at it for the last half hour, but configure.ac
> syntax defeats me :-D (I figured getting the check into configure.ac
> would be a good first start)
Errr... doesn't configure.ac have checking for asciidoc version? Search
for AC_CHECK_PROGS(ASCIIDOC, [asciidoc]). Perhaps tests should be more
detailed, or something...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: asciidoc, was Re: Chicken/egg problem building from a 'git clone'
From: John Tapsell @ 2009-03-06 12:28 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Jeff King, Matthieu Moy, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0903061301340.10279@pacific.mpi-cbg.de>
2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 6 Mar 2009, John Tapsell wrote:
>
>> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>> > On Fri, 6 Mar 2009, Jakub Narebski wrote:
>> >
>> >> Jeff King <peff@peff.net> writes:
>> >> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
>> >> >
>> >> >>>> * we have lots other files in git.git that are autogenerated (the
>> >> >>>> documentation files, for example)
>> >> >>>
>> >> >>> I'm not aware of any auto-generated files that are checked in. Can you
>> >> >>> give an example?
>> >> >>
>> >> >> man pages and html docs are commited, but in a separate branch. IOW,
>> >> >> Junio abuses Git as a distribution mechanism, but keeps it totally
>> >> >> separate from the actual sources.
>> >> >
>> >> > OK, true; but that is a totally different mechanism, unless the proposal
>> >> > is to autobuild a "this would be the release tarball" branch similar to
>> >> > html and man branches.
>> >>
>> >> I thnk the proposal was to have 'configure' branch with configure
>> >> script built, similar to how 'html' and 'man' branches have built
>> >> documentation in HTML and manpages format.
>> >>
>> >> However while toolchain needed to produce documentation (asciidoc +
>> >> xmlto) isn't, I think, something very common, in my opinion autoconf is
>> >> something that is present on systems containing other build tools
>> >> required to build git from sources. So 'configure' branch is not, I
>> >> think, as necessary as 'html' and 'man' branches; additionally 'html'
>> >> branch (or the repository used to build documentation, or the byproduct
>> >> of building documentation) is used to generate on-line docs for git.
>> >
>> > Plus, keep in mind that autoconf support is only an afterthought in Git;
>> > Just running "make" is supposed to work. If it does not, patches are
>> > certainly welcome, I think.
>>
>> Well now that you mention it.. :-)
>>
>> It doesn't check for the existance of asciidoc, but blindly assumes it
>> exists. And even if you do have asciidoc, there's a good chance that
>> you have the wrong version. The INSTALL file says that asciidoc
>> requires 8.2.7 but most distros (debian, ubuntu. probably other) have
>> 8.2.6.
>> If you compile the docs with the wrong asciidoc version, there is no
>> warning or error at all. It just builds incorrect man pages.
>
> Frankly, I was talking about "make". I never needed asciidoc there.
>
> Besides, if it is really an itch of yours, maybe you can come up with a
> patch checking for a correct asciidoc version? Only if asciidoc would be
> needed at all, of course.
Yep. I've been looking at it for the last half hour, but configure.ac
syntax defeats me :-D (I figured getting the check into configure.ac
would be a good first start)
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: John Tapsell @ 2009-03-06 12:26 UTC (permalink / raw)
To: Finn Arne Gangstad
Cc: Junio C Hamano, Johannes Schindelin, Sverre Rabbelier,
markus.heidelberg, git, Andreas Ericsson
In-Reply-To: <20090306114812.GA19534@pvv.org>
2009/3/6 Finn Arne Gangstad <finnag@pvv.org>:
> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>> >
>> >> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
>> >> <markus.heidelberg@web.de> wrote:
>> >> > Oh, I confused "config option" with "command line argument"...
>> >>
>> >> Right, I'd like to be able to do:
>> >> $ git config push.iamnotretarded true
>> >> $ git push
>> >
>> > LOL! Sverre, you have a way to crack me up...
>>
>> I found it amusing, too.
>>
>> It may have some correlation with how well organized your work habit is,
>> but I do not think it has much correlation with being retarded. It is
>> more about "'matching refs' is the perfect default for _my_ use pattern,
>> don't mess with it, please".
>
> So here is my current WIP suggestion for a new "push.default"
> variable, I am not sure if a single entry can express all useful
> choices, or if it is a good idea to introduce more default choices
> other than "nothing" (with the goal of making it the default in a
> later release).
>
> I think all the values here make sense as a --option to git push
> though (except --nothing...)
>
> Suggested new entry in config.txt:
>
> push.default::
> Defines the action git push should take if no refspec is given
> on the command line, no refspec is configured in the branch, and
> no refspec is implied by any of the options given on the command
> line.
> +
> The term `current remote` means the remote configured for the current
> branch, or `origin` if no remote is set. `origin` is also used if
> you are not on a branch at all.
> +
> * `nothing` do not push anything
> * `matching` push all matching branches to the current remote.
> All branches having the same name in both ends are considered to be
> matching. This is the default value.
> * `same-remote` push all matching branches that are configured to use
> the current remote. Branches with no remote configuration are not pushed.
> * `tracked` push all branches that are tracking a branch on the current
> remote to their counterpart.
How about 'current', to simply push the current the branch. It could
even prompt if it's not tracked yet.
Most (all?) other revision control systems have this 'current'
behaviour by default.
John
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jeff King @ 2009-03-06 12:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Miles Bader, git
In-Reply-To: <7vk573t4cm.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 06, 2009 at 12:58:33AM -0800, Junio C Hamano wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
> > Yeah, that part is easy. I wasn't sure the best way to handle places
> > where a constant date_mode is used e.g.:
> >
> > pp_user_info(NULL, CMIT_FMT_EMAIL, &sb, committer, DATE_RFC2822,
> > encoding);
>
> One approach that will be hated by libgit2 effort would be to keep the
> date_mode an enum as before (sans DATE_LOCAL) and make the "tz_offset"
> thing as a setting global to the process, defined in environ.c
I haven't looked, but might it not be possible to put it in the rev_info
struct next to the date format, but not as part of a struct? You will
then sometimes have to pass two options around (the format and the tz
offset) instead of one (the struct with both), but it makes split usage
much easier:
pp_user_info(NULL, CMIT_FMT_EMAIL, &sb, committer, DATE_RFC2822,
revs->tz_offset, encoding);
-Peff
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jeff King @ 2009-03-06 12:10 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <76718490903052258j277fa8e9g963deae1c3264a22@mail.gmail.com>
On Fri, Mar 06, 2009 at 01:58:36AM -0500, Jay Soffian wrote:
> 1) The CLI. You and Jeff don't seem to have an agreement here, but
> frankly, this is the easy part.
>
> 2) The internal implementation. Your implementation (enum -> bitfield)
> is clever, but Jeff seems to prefer what I suggested (going to a
> struct). The latter is quite a bit more work.
My argument for (2), btw, is that the code is easier to read and more
maintainable if it follows the structure of the CLI. But I don't think
it's as important as getting the CLI right.
-Peff
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jeff King @ 2009-03-06 12:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Miles Bader, git
In-Reply-To: <7vmybzw3el.fsf@gitster.siamese.dyndns.org>
On Thu, Mar 05, 2009 at 10:50:42PM -0800, Junio C Hamano wrote:
> > Because from the user's perspective --foo={bar,baz,bleep} is about
> > selecting exactly one of {bar,baz,bleep}.
>
> I do not feel very strongly about this either way, and without any prior
> end user "Huh?" input, I would probably have argued like you myself, but
> I saw the original message from Miles about giving more than one --date
> and getting perplexed to see that it did not work, so...
Interesting. I saw the original message from Miles as "I tried to use
more than one --date, but that seems wrong to me because these concepts
are orthogonal". But I do recognize that it is somewhat a matter of
perception and style.
Anyway, as our one user in this thread, he has said the separate option
is more clear. So I think we should go with that.
-Peff
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Johannes Schindelin @ 2009-03-06 12:07 UTC (permalink / raw)
To: Finn Arne Gangstad
Cc: Junio C Hamano, Sverre Rabbelier, markus.heidelberg, git,
John Tapsell, Andreas Ericsson
In-Reply-To: <20090306114812.GA19534@pvv.org>
Hi,
On Fri, 6 Mar 2009, Finn Arne Gangstad wrote:
> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
> > >
> > >> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
> > >> <markus.heidelberg@web.de> wrote:
> > >> > Oh, I confused "config option" with "command line argument"...
> > >>
> > >> Right, I'd like to be able to do:
> > >> $ git config push.iamnotretarded true
> > >> $ git push
> > >
> > > LOL! Sverre, you have a way to crack me up...
> >
> > I found it amusing, too.
> >
> > It may have some correlation with how well organized your work habit is,
> > but I do not think it has much correlation with being retarded. It is
> > more about "'matching refs' is the perfect default for _my_ use pattern,
> > don't mess with it, please".
>
> So here is my current WIP suggestion for a new "push.default"
> variable, I am not sure if a single entry can express all useful
> choices, or if it is a good idea to introduce more default choices
> other than "nothing" (with the goal of making it the default in a
> later release).
Speaking of which, Steffen (who cannot reply right now, since he is AFK
for a while) had a patch to install "remote.<branch>.push = HEAD" with
clone and remote. Would that be better?
Ciao,
Dscho
^ permalink raw reply
* asciidoc, was Re: Chicken/egg problem building from a 'git clone'
From: Johannes Schindelin @ 2009-03-06 12:02 UTC (permalink / raw)
To: John Tapsell; +Cc: Jakub Narebski, Jeff King, Matthieu Moy, Git Mailing List
In-Reply-To: <43d8ce650903060327l64e76f2al7ec3c2ee76be14eb@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2548 bytes --]
Hi,
On Fri, 6 Mar 2009, John Tapsell wrote:
> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 6 Mar 2009, Jakub Narebski wrote:
> >
> >> Jeff King <peff@peff.net> writes:
> >> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
> >> >
> >> >>>> * we have lots other files in git.git that are autogenerated (the
> >> >>>> documentation files, for example)
> >> >>>
> >> >>> I'm not aware of any auto-generated files that are checked in. Can you
> >> >>> give an example?
> >> >>
> >> >> man pages and html docs are commited, but in a separate branch. IOW,
> >> >> Junio abuses Git as a distribution mechanism, but keeps it totally
> >> >> separate from the actual sources.
> >> >
> >> > OK, true; but that is a totally different mechanism, unless the proposal
> >> > is to autobuild a "this would be the release tarball" branch similar to
> >> > html and man branches.
> >>
> >> I thnk the proposal was to have 'configure' branch with configure
> >> script built, similar to how 'html' and 'man' branches have built
> >> documentation in HTML and manpages format.
> >>
> >> However while toolchain needed to produce documentation (asciidoc +
> >> xmlto) isn't, I think, something very common, in my opinion autoconf is
> >> something that is present on systems containing other build tools
> >> required to build git from sources. So 'configure' branch is not, I
> >> think, as necessary as 'html' and 'man' branches; additionally 'html'
> >> branch (or the repository used to build documentation, or the byproduct
> >> of building documentation) is used to generate on-line docs for git.
> >
> > Plus, keep in mind that autoconf support is only an afterthought in Git;
> > Just running "make" is supposed to work. If it does not, patches are
> > certainly welcome, I think.
>
> Well now that you mention it.. :-)
>
> It doesn't check for the existance of asciidoc, but blindly assumes it
> exists. And even if you do have asciidoc, there's a good chance that
> you have the wrong version. The INSTALL file says that asciidoc
> requires 8.2.7 but most distros (debian, ubuntu. probably other) have
> 8.2.6.
> If you compile the docs with the wrong asciidoc version, there is no
> warning or error at all. It just builds incorrect man pages.
Frankly, I was talking about "make". I never needed asciidoc there.
Besides, if it is really an itch of yours, maybe you can come up with a
patch checking for a correct asciidoc version? Only if asciidoc would be
needed at all, of course.
Ciao,
Dscho
^ 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