* Re: [rfc] git submodules howto
From: J. Bruce Fields @ 2007-09-18 15:55 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918154734.GP19019@genesis.frugalware.org>
On Tue, Sep 18, 2007 at 05:47:34PM +0200, Miklos Vajna wrote:
> On Tue, Sep 18, 2007 at 09:29:40AM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > > 2) does this worth adding to the documentation? maybe to a .txt under
> > > Documentation/howto? or to git-submodule.txt?
> >
> > Could you add it as a new chapter to user-manual.txt (probably just
> > after the "git concepts" chapter), and then add links to that chapter
> > from git-submodule(1) and gitmodules(5)?
>
> hm, i did not know about the wiki page Michael created yesterday. so i
> don't know what's the rule in case: if something is already in the wiki
> then should or should not it be added to the 'official docs'?
It should. We also need submodules documentation for the "official"
documentation.
If you want to base that work off of that wiki page instead of your
original email, that's fine. Just make sure you get Michael's
permission first.
--b.
^ permalink raw reply
* Re: testsuite problems
From: Miklos Vajna @ 2007-09-18 15:52 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <46EFE75D.7000805@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]
On Tue, Sep 18, 2007 at 04:57:33PM +0200, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Info-ZIP zip and unzip are two different programs, each with their
> own version numbers.
ah, my bad.
> >> Also, what is the difference between t/trash/a and t/trash/d/a after
> >> running the test script (that's what test 21 is comparing)?
> >
> > $ diff -Naur t/trash/a t/trash/d/a
> > diff -Naur t/trash/a/l1 t/trash/d/a/l1
> > --- t/trash/a/l1 2007-09-17 23:10:03.000000000 +0200
> > +++ t/trash/d/a/l1 2007-09-17 23:10:03.000000000 +0200
> > @@ -1 +1 @@
> > -simple textfile
> > +a
> > \ No newline at end of file
>
> Ah! l1 is a symlink to a. The target of a symlink is stored as file
> content in a ZIP archive and marked with a special flag. An unzipper
> that doesn't understand this flag would create a file containing the
> link target's name instead of a symlink pointing to the target.
>
> The unzip on my system says:
>
> $ unzip -v
> UnZip 5.52 of 28 February 2005, by Ubuntu. Original by Info-ZIP.
>
> Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
> see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
>
> Compiled with gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4) for Unix (Linux ELF) on Mar 31 2007.
>
> UnZip special compilation options:
> ACORN_FTYPE_NFS
> COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
> SET_DIR_ATTRIB
> TIMESTAMP
> USE_EF_UT_TIME
> USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
> USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
> VMS_TEXT_CONV
> WILD_STOP_AT_DIR
> [decryption, version 2.9 of 05 May 2000]
>
> I suspect you need SET_DIR_ATTRIB in order to extract symlinks.
$ unzip -v
UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler.
Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for
details.
Latest sources and executables are at
ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.1.2 for Unix (Linux ELF) on May 9 2007.
UnZip special compilation options:
ASM_CRC
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
[decryption, version 2.9 of 05 May 2000]
if i'm not wrong then these options should be ok. :S
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: State of Perforce importing.
From: David Brown @ 2007-09-18 15:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git
In-Reply-To: <46EF7DD1.9090301@vilain.net>
On Tue, Sep 18, 2007 at 07:27:13PM +1200, Sam Vilain wrote:
>I'm pretty close to giving a newer one a spin, that actually imports
>from the raw perforce back-end files without needing the perforce
>server. I am hoping that this should give a very clean import and will
>be very fast and efficient, sending files that share ancestry to gfi in
>sequence so that the on-the-fly delta system works.
Unfortunately, this isn't something I'm going to be able to use. The
Perforce server will remain live, and resides on a machine I don't have
access to.
>It could possibly be adapted to use the p4 client (though I'd expect
>that to be relatively slow per-revision), and possibly be extended to be
>bidirectional as all of the upstream change number information is
>recorded, a la git-svn.
I was able to get 'git-p4' to work a lot better by using @all, but it still
has some problems, at least bad interactions with P4.
- It doesn't use any client spec. Our P4 server space is a complete
mismash and has to be fixed up to get a sane directory layout. For
example, some revisions have hundred-MB tar files sitting in the root
directory and I don't want that in the repo. I also need to exclude
directories, and in some cases completely rearrange the directory
layout.
- Our P4 server is set to be case insensitive. 'git-p4' ignores paths
that come back from the server that are specified using a different
case. Unfortunately, this means that a handful of files just get
randomly dropped from each revision.
I tried importing a client path instead of a depot path, but the names
that come back from 'p4 files' are depot based so none ever match. I
end up with a nice revision history of entirely empty trees.
I'm probably going to end up writing an importer that uses an actual client
workspace to let Perforce do the client mapping. I'm also going to have to
put some work into some code to clean up the log messages, since most of
our changes have as a first line "New Features:", which makes for a rather
uninformative shortlog.
But, I did learn about 'p4 -G' from git-p4 so that will help in getting
information from the repository.
Thanks,
David
^ permalink raw reply
* Latest builtin-commit series
From: Kristian Høgsberg @ 2007-09-18 15:23 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Hi,
I sent out a new builtin-commit patch series last night, and figured I
should have written a cover letter to describe the changes there.
Better late than never:
* rebase to Pierres strbuf changes. Note, there is still some
strbuf tweaking required, to let stripspace work on a strbuf.
Also, I changed the semantics of stripspace to always add a
newline if the last line doesn't have one. I believe the
current odd semantics (always remove the last newline) comes
from not being able to easily add a newline, but now that it's a
strbuf, that's easy.
* Fixing the last bug that caused trouble in the test suite: even
if run_status says there's nothing to commit, proceed if we're
doing a merge.
* Set the test suite default editor to '/bin/true' instead of ':'.
Since we're not exec'ing the editor from shell anymore, ':'
won't work. Maybe we should special case ':' in launch_editor
or perhaps make launch_editor use system(3). Not sure.
* The first few patches are good to go, and if we can get them
committed to next, we can focus on the builtin-commit patch.
Specifically:
0001-Enable-wt-status-output-to-a-given-FILE-pointer.patch
0002-Enable-wt-status-to-run-against-non-standard-index-f.patch
0003-Introduce-entry-point-for-launching-add-interactive.patch
0004-Clean-up-stripspace-a-bit-use-strbuf-even-more.patch
0005-Add-strbuf_read_file.patch
0006-Export-rerere-and-launch_editor.patch
(edit our "and launch_editor" from the title)
should all be fine and easy to review, whereas
0007-Implement-git-commit-as-a-builtin-command.patch
will probably need some careful reviewing. That said, it is
feature complete, the code is nice enough and it passes the test
suite. It's just a very important part of git :)
cheers,
Kristian
(sorry about the duplicate mail)
^ permalink raw reply
* Re: [rfc] git submodules howto
From: Miklos Vajna @ 2007-09-18 15:47 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070918132940.GC12120@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
On Tue, Sep 18, 2007 at 09:29:40AM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > 2) does this worth adding to the documentation? maybe to a .txt under
> > Documentation/howto? or to git-submodule.txt?
>
> Could you add it as a new chapter to user-manual.txt (probably just
> after the "git concepts" chapter), and then add links to that chapter
> from git-submodule(1) and gitmodules(5)?
hm, i did not know about the wiki page Michael created yesterday. so i
don't know what's the rule in case: if something is already in the wiki
then should or should not it be added to the 'official docs'?
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Latest builtin-commit series
From: Kristian Høgsberg @ 2007-09-18 15:12 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Hi,
I sent out a new builtin-commit patch series last night, and figured I
should have written a cover letter to describe the changes there.
Better late than never:
* rebase to Pierres strbuf changes. Note, there is still some
strbuf tweaking required, to let stripspace work on a strbuf.
Also, I changed the semantics of stripspace to always add a
newline if the last line doesn't have one. I believe the
current odd semantics (always remove the last newline) comes
from not being able to easily add a newline, but now that it's a
strbuf, that's easy.
^ permalink raw reply
* Re: [PATCH 7/7] Implement git commit as a builtin command.
From: Kristian Høgsberg @ 2007-09-18 15:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709181453220.28586@racer.site>
On Tue, 2007-09-18 at 14:58 +0100, Johannes Schindelin wrote:
> Hi,
>
> very nice!
>
> Four nits, though, and a half:
>
> - it would be nicer to put the option parsing it option.[ch] (you would
> also need to pass the usage line then, instead of hardwiring it to
> "git_commit_usage"),
Yes, good point.
> - it seems more logical to me to call it "parse_option()" than
> "scan_options()", since that is what it does,
Yup.
> - you might want to rename OPTION_NONE to OPTION_BOOLEAN, and maybe even
> allow "--no-<option>" in that case for free,
Agree.
> - wt_status_prepare() could take a parameter "index_file", which would
> default to git_path("index") when passed as NULL, and
Yeah, the way I did it, I preserved the API, but that's not really a
concern, I guess.
> - launch_editor() is defined in builtin-tag.c, which is not part of the
> library, and therefore it would be technically more correct to either
> move the function to editor.c (my preferred solution), or declare it in
> builtin.h instead of strbuf.h.
Yeah, and we should move the stripspace code there too. Or maybe we
should rename that strbuf_stripspace and put it in strbuf.c.
> As you can see, my nits are really minor, which means that I am pretty
> happy with your work!
Great, I hope we can get it in soon :)
Kristian
^ permalink raw reply
* Re: [PATCH 3/5] Correct handling of branch.$name.merge in builtin-fetch
From: Daniel Barkalow @ 2007-09-18 15:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070918085453.GC5390@spearce.org>
On Tue, 18 Sep 2007, Shawn O. Pearce wrote:
> My prior bug fix for git-push titled "Don't configure remote "." to
> fetch everything to itself" actually broke t5520 as we were unable
> to evaluate a branch configuration of:
>
> [branch "copy"]
> remote = .
> merge = refs/heads/master
>
> as remote "." did not have a "remote...fetch" configuration entry to
> offer up refs/heads/master as a possible candidate available to be
> fetched and merged. In shell script git-fetch and prior to the above
> mentioned commit this was hardcoded for a url of "." to be the set of
> local branches.
Ah, right. When you removed that, I remembered there being some reason I'd
put it in, but I couldn't remember what it was, and knew you'd turn it up
before I would.
> Chasing down this bug led me to the conclusion that our prior behavior
> with regards to branch.$name.merge was incorrect. In the shell script
> based git-fetch implementation we only fetched and merged a branch if
> it appeared both in branch.$name.merge *and* in remote.$r.fetch, where
> $r = branch.$name.remote. In other words in the following config file:
>
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/git/git.git
> fetch = refs/heads/master:refs/remotes/origin/master
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [branch "pu"]
> remote = origin
> merge = refs/heads/pu
>
> Attempting to run `git pull` while on branch "pu" would always give
> the user "Already up-to-date" as git-fetch did not fetch pu and thus
> did not mark it for merge in .git/FETCH_HEAD. The configured merge
> would always be ignored and the user would be left scratching her
> confused head wondering why merge did not work on "pu" but worked
> fine on "master".
>
> If we are using the "default fetch" specification for the current
> branch and the current branch has a branch.$name.merge configured
> we now union it with the list of refs in remote.$r.fetch. This
> way the above configuration does what the user expects it to do,
> which is to fetch only "master" by default but when on "pu" to
> fetch both "master" and "pu".
And store master, but don't store pu. This looks like the right solution
to me.
> This uncovered some breakage in the test suite where old-style Cogito
> branches (.git/branches/$r) did not fetch the branches listed in
> .git/config for merging and thus did not actually merge them if the
> user tried to use `git pull` on that branch. Junio and I discussed
> it on list and felt that the union approach here makes more sense to
> DWIM for the end-user than silently ignoring their configured request
> so the test vectors for t5515 have been updated to include for-merge
> lines in .git/FETCH_HEAD where they have been configured for-merge
> in .git/config.
Ah, okay. This is one of the things I'd changed, to make it obey the merge
configuration (which meant that it didn't get anything to merge), which
had previously been ignored. So there's nothing that's expecting exactly
the behavior that you're changing away from, except for that test case.
This whole series looks good to me.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: testsuite problems
From: René Scharfe @ 2007-09-18 14:57 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070917220408.GG19019@genesis.frugalware.org>
Miklos Vajna schrieb:
> On Mon, Sep 17, 2007 at 11:50:32PM +0200, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>> The failing tests check ZIP file creation, not tar file creation.
>> Perhaps your unzip command works a bit differently from Info-ZIP's?
>
> $ zip -v
> Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license.
> This is Zip 2.32 (June 19th 2006), by Info-ZIP.
>
> should this version be ok?
Info-ZIP zip and unzip are two different programs, each with their
own version numbers.
>> Also, what is the difference between t/trash/a and t/trash/d/a after
>> running the test script (that's what test 21 is comparing)?
>
> $ diff -Naur t/trash/a t/trash/d/a
> diff -Naur t/trash/a/l1 t/trash/d/a/l1
> --- t/trash/a/l1 2007-09-17 23:10:03.000000000 +0200
> +++ t/trash/d/a/l1 2007-09-17 23:10:03.000000000 +0200
> @@ -1 +1 @@
> -simple textfile
> +a
> \ No newline at end of file
Ah! l1 is a symlink to a. The target of a symlink is stored as file
content in a ZIP archive and marked with a special flag. An unzipper
that doesn't understand this flag would create a file containing the
link target's name instead of a symlink pointing to the target.
The unzip on my system says:
$ unzip -v
UnZip 5.52 of 28 February 2005, by Ubuntu. Original by Info-ZIP.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4) for Unix (Linux ELF) on Mar 31 2007.
UnZip special compilation options:
ACORN_FTYPE_NFS
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
WILD_STOP_AT_DIR
[decryption, version 2.9 of 05 May 2000]
I suspect you need SET_DIR_ATTRIB in order to extract symlinks.
René
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: Felipe Balbi @ 2007-09-18 14:39 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqc03vrq.fsf@lola.quinscape.zz>
Hi,
On 9/18/07, David Kastrup <dak@gnu.org> wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Tue, Sep 18, 2007 at 09:40:55AM +0200, Andreas Ericsson wrote:
> >> Felipe Balbi wrote:
> >>> From: Felipe Balbi <felipe.lima@indt.org.br>
> >>> This patch adds a --suppress-all option to avoid sending emails
> >>> to everybody but the ones listed by --to option.
> >>
> >> To my minds eye, --suppress-all is equivalent to --dry-run. Could you
> >> rename it to "--cc-nobody" or some such?
> >>
> >> On a side-note, I've never really understood why git-send-email *by
> >> default*
> >> sends to a bazillion people. Does anybody ever use it without suppressing
> >> most of the CC targets?
> >
> > Yes. I never suppress the cc's. The cc-everyone thing is standard on
> > the kernel mailing lists.
> >
> > The one exception is if I'm just sending the series to myself as a test.
>
> Wouldn't --no-cc be a nicer option name?
It'll probably conflict if I don't wanna CC patch's author nor
Signed-off-by but DO want to CC somebody special like the maintainer.
the option is changed to --cc-nobody and it's already resent. :-)
>
> --
> David Kastrup
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: [PATCH 1/3] git-apply: fix whitespace stripping
From: David Kastrup @ 2007-09-18 14:18 UTC (permalink / raw)
To: git
In-Reply-To: <20070918131237.GA12120@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Sep 18, 2007 at 10:55:25AM +0200, David Kastrup wrote:
>> As far as I can see, this does not really work since it does not
>> maintain an idea of a current column.
>>
>> If you have
>>
>> abcd<four spaces><tab><four spaces><tab>
>>
>> then indeed the resulting conversion needs to be <tab><tab><tab>
>> whereas with
>>
>> abc<four spaces><tab><four spaces><tab>
>>
>> the resulting conversion needs to be just <tab><tab>
>
> Note that this code *only* handles whitespace in the initial indent;
> processing stops as soon as it hits anything other than a tab or an
> indent.
>
> Given that, I believe the proposed patch is correct. Am I missing
> something else?
Don't think so. Sorry for the noise.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Sam Vilain @ 2007-09-18 14:34 UTC (permalink / raw)
To: Lars Hjemli
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709180701m54810d80nefa4704abb8797dd@mail.gmail.com>
Lars Hjemli wrote:
> Ok. I'll try to explain why I needed --no-ff in the first place:
>
> I have two git-svn brances, lets call them FEATURE and RELEASE. At one
> point, I did
> $ git checkout FEATURE
> $ git merge RELEASE
> $ git svn dcommit
>
> Now, my coworkers can continue testing/developing on top of the
> subversion branch FEATURE (I'm currently the only git user), knowing
> that every bugfix from RELEASE have been merged.
>
> A few days later, FEATURE is completed and tested and should be
> integrated in RELEASE. I did
>
> $ git checkout RELEASE
> $ git merge FEATURE
> $ git svn dcommit -n
>
> and noticed that git-svn wanted to commit the result to FEATURE, since
> the merge actually was a fast-forward. If this was a a pure git
> environment it would be no problem, but as I needed to get a merge
> revision on top of the subversion RELEASE branch, I was in trouble.
>
I understand. But if you could specify a target branch of "RELEASE" to
dcommit (which git-svn might know based on which svn tracking branch it
was branched from), then it should be able to do the same thing that
'svn merge' would do on svn 1.5+, or 'svk sm' does. Which is to write
to the SVN repository a squash merge, and write svn properties to let
merge-aware svn tools know which SVN revisions are being squashed.
> My options:
> * rebase FEATURE onto RELEASE: this would have duplicated ~150
> revisions from FEATURE onto RELEASE in subversion
>
Yes, not desirable.
> * merge --squash: this would have created the wanted history in
> subversion, but my git history would have lacked the info that
> everything in FEATURE had been integrated into RELEASE (this could
> have been fixed by editing the grafts file)
>
This is a current deficiency in git-svn; bidirectional merge tracking is
not there yet.
> * merge --no-ff: this made both the subversion history and my local
> git history reflect what actually happened.
>
> So I went for the --no-ff option.
>
> If this use-case isn't good enough, oh well. I can always carry the
> patch forward in my git repo ;-)
>
And you'll probably need to keep it around until bidirectional merge
handling is in.
Sam.
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: David Kastrup @ 2007-09-18 14:15 UTC (permalink / raw)
To: git
In-Reply-To: <20070918132251.GB12120@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Sep 18, 2007 at 09:40:55AM +0200, Andreas Ericsson wrote:
>> Felipe Balbi wrote:
>>> From: Felipe Balbi <felipe.lima@indt.org.br>
>>> This patch adds a --suppress-all option to avoid sending emails
>>> to everybody but the ones listed by --to option.
>>
>> To my minds eye, --suppress-all is equivalent to --dry-run. Could you
>> rename it to "--cc-nobody" or some such?
>>
>> On a side-note, I've never really understood why git-send-email *by
>> default*
>> sends to a bazillion people. Does anybody ever use it without suppressing
>> most of the CC targets?
>
> Yes. I never suppress the cc's. The cc-everyone thing is standard on
> the kernel mailing lists.
>
> The one exception is if I'm just sending the series to myself as a test.
Wouldn't --no-cc be a nicer option name?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 14:01 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <46EFD0F8.5050603@vilain.net>
On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> Lars Hjemli wrote:
> > On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> >> If you really want one, use git commit-tree directly.
> >>
> > Yeah, that's an option, but --no-ff is somewhat less work ;-)
> >
>
> Sure. I just don't see a good use case for it from this yet.
Ok. I'll try to explain why I needed --no-ff in the first place:
I have two git-svn brances, lets call them FEATURE and RELEASE. At one
point, I did
$ git checkout FEATURE
$ git merge RELEASE
$ git svn dcommit
Now, my coworkers can continue testing/developing on top of the
subversion branch FEATURE (I'm currently the only git user), knowing
that every bugfix from RELEASE have been merged.
A few days later, FEATURE is completed and tested and should be
integrated in RELEASE. I did
$ git checkout RELEASE
$ git merge FEATURE
$ git svn dcommit -n
and noticed that git-svn wanted to commit the result to FEATURE, since
the merge actually was a fast-forward. If this was a a pure git
environment it would be no problem, but as I needed to get a merge
revision on top of the subversion RELEASE branch, I was in trouble.
My options:
* rebase FEATURE onto RELEASE: this would have duplicated ~150
revisions from FEATURE onto RELEASE in subversion
* merge --squash: this would have created the wanted history in
subversion, but my git history would have lacked the info that
everything in FEATURE had been integrated into RELEASE (this could
have been fixed by editing the grafts file)
* merge --no-ff: this made both the subversion history and my local
git history reflect what actually happened.
So I went for the --no-ff option.
If this use-case isn't good enough, oh well. I can always carry the
patch forward in my git repo ;-)
--
larsh
^ permalink raw reply
* Re: [PATCH 7/7] Implement git commit as a builtin command.
From: Johannes Schindelin @ 2007-09-18 13:58 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11900740163661-git-send-email-krh@redhat.com>
Hi,
very nice!
Four nits, though, and a half:
- it would be nicer to put the option parsing it option.[ch] (you would
also need to pass the usage line then, instead of hardwiring it to
"git_commit_usage"),
- it seems more logical to me to call it "parse_option()" than
"scan_options()", since that is what it does,
- you might want to rename OPTION_NONE to OPTION_BOOLEAN, and maybe even
allow "--no-<option>" in that case for free,
- wt_status_prepare() could take a parameter "index_file", which would
default to git_path("index") when passed as NULL, and
- launch_editor() is defined in builtin-tag.c, which is not part of the
library, and therefore it would be technically more correct to either
move the function to editor.c (my preferred solution), or declare it in
builtin.h instead of strbuf.h.
As you can see, my nits are really minor, which means that I am pretty
happy with your work!
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 4/7] Clean up stripspace a bit, use strbuf even more.
From: Kristian Høgsberg @ 2007-09-18 13:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709181411200.28586@racer.site>
On Tue, 2007-09-18 at 14:12 +0100, Johannes Schindelin wrote:
> Hi,
>
> I really like your patch, except for this:
>
> On Mon, 17 Sep 2007, Kristian Høgsberg wrote:
>
> > diff --git a/builtin.h b/builtin.h
> > index 03ee7bf..d6f2c76 100644
> > --- a/builtin.h
> > +++ b/builtin.h
> > @@ -7,7 +7,6 @@ extern const char git_version_string[];
> > extern const char git_usage_string[];
> >
> > extern void help_unknown_cmd(const char *cmd);
> > -extern size_t stripspace(char *buffer, size_t length, int skip_comments);
> > extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
> > extern void prune_packed_objects(int);
> >
> > diff --git a/strbuf.h b/strbuf.h
> > index 21fc111..5960637 100644
> > --- a/strbuf.h
> > +++ b/strbuf.h
> > @@ -98,4 +98,6 @@ extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
> >
> > extern void read_line(struct strbuf *, FILE *, int);
> >
> > +extern void stripspace(struct strbuf *buf, int skip_comments);
> > +
> > #endif /* STRBUF_H */
>
> If you do that, you have to move the function "stripspace" to strbuf.c,
> too...
Right, the alternative is to #include strbuf.h in builtin.h, or maybe
just add struct strbuf; at the top. And with Pierres latest patch
strbuf is included everywhere, so maybe this is already moot.
Kristian
^ permalink raw reply
* Re: [rfc] git submodules howto
From: J. Bruce Fields @ 2007-09-18 13:29 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918105538.GL19019@genesis.frugalware.org>
On Tue, Sep 18, 2007 at 12:55:38PM +0200, Miklos Vajna wrote:
> 1) is this correct? :) i use it and it seem to do what i except, but
> maybe it's not correct
I'm not able to answer that question.
> 2) does this worth adding to the documentation? maybe to a .txt under
> Documentation/howto? or to git-submodule.txt?
Could you add it as a new chapter to user-manual.txt (probably just
after the "git concepts" chapter), and then add links to that chapter
from git-submodule(1) and gitmodules(5)?
--b.
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: Felipe Balbi @ 2007-09-18 13:29 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Andreas Ericsson, git, Felipe Balbi
In-Reply-To: <20070918132251.GB12120@fieldses.org>
Hi,
On 9/18/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Tue, Sep 18, 2007 at 09:40:55AM +0200, Andreas Ericsson wrote:
> > Felipe Balbi wrote:
> >> From: Felipe Balbi <felipe.lima@indt.org.br>
> >> This patch adds a --suppress-all option to avoid sending emails
> >> to everybody but the ones listed by --to option.
> >
> > To my minds eye, --suppress-all is equivalent to --dry-run. Could you
> > rename it to "--cc-nobody" or some such?
> >
> > On a side-note, I've never really understood why git-send-email *by
> > default*
> > sends to a bazillion people. Does anybody ever use it without suppressing
> > most of the CC targets?
>
> Yes. I never suppress the cc's. The cc-everyone thing is standard on
> the kernel mailing lists.
>
> The one exception is if I'm just sending the series to myself as a test.
And that the motivation for this patch :-p
Internally (in my company, where I work), we send patches to each
other for code review before sending it publicly.
>
> --b.
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Sam Vilain @ 2007-09-18 13:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Andreas Ericsson, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0709181334210.28586@racer.site>
Johannes Schindelin wrote:
>> I personally want to be able to dump patches, including merges, to
>> git-format-patch format, in such a way that all other information (eg,
>> committer, date, etc) is preserved.
>>
>
> We already talked about that on IRC, and you have not even _begun_ to
> think about the fundamental issues with merges-in-a-patch. I mentioned a
> few on IRC, and am still awaiting your reply.
>
Well, you could store diffs from both parents, or a custom diff format
that marks different ancestors, etc. Sure, they wouldn't apply with
'patch', but that's the breaks.
I don't see the encoding of the information as such a fundamental and
insurmountable issue. Why do you consider it so?
Sam.
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: J. Bruce Fields @ 2007-09-18 13:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Felipe Balbi, git, Felipe Balbi
In-Reply-To: <46EF8107.1030607@op5.se>
On Tue, Sep 18, 2007 at 09:40:55AM +0200, Andreas Ericsson wrote:
> Felipe Balbi wrote:
>> From: Felipe Balbi <felipe.lima@indt.org.br>
>> This patch adds a --suppress-all option to avoid sending emails
>> to everybody but the ones listed by --to option.
>
> To my minds eye, --suppress-all is equivalent to --dry-run. Could you
> rename it to "--cc-nobody" or some such?
>
> On a side-note, I've never really understood why git-send-email *by
> default*
> sends to a bazillion people. Does anybody ever use it without suppressing
> most of the CC targets?
Yes. I never suppress the cc's. The cc-everyone thing is standard on
the kernel mailing lists.
The one exception is if I'm just sending the series to myself as a test.
--b.
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Sam Vilain @ 2007-09-18 13:22 UTC (permalink / raw)
To: Lars Hjemli
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709180503g24ef6c5hda2877e2215ba58d@mail.gmail.com>
Lars Hjemli wrote:
> [...sorry for making this such a long thread...]
>
> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>
>> Lars Hjemli wrote:
>>
>>> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>>>
>>>
>>>> I think that writing a real fast-forward merge should only happen on
>>>> dcommit, not git merge, because that is what is required for SVN.
>>>>
>>>>
>>> I don't think git-svn has any way of knowing that the user wanted a
>>> merge, unless a merge commit is present. So the user would have to
>>> specify the set of commits which should be considered a merge during
>>> dcommit (this would actually resemble how merges are performed in
>>> subversion).
>>>
>>>
>> Sure it can. If you're committing to branch X, and the current tree has
>> a whole lot of commits above that, then it should do the only thing you
>> can do with SVN.
>>
>> Which is write a squash commit, and set the "svn:merge" and/or
>> "svk:merge" properties to represent what happened.
>>
>
> I often have prepared a series of local commits which I _want_ to
> preserve as different subversion revisions.
>
But for the scenario we are discussing the revisions already exist
upstream otherwise there would be no fast forward merge. So, if you
want that behaviour you can use cherry-pick on the git side and the
correct behaviour for git-svn is to write svn merge properties.
> Also, doing a --squash means that I loose the merge history in git
> (and then I need to edit the grafts file again)
>
There is no merge history in git, it was a fast forward.
>>> Sidenote: this might be slightly controversial, but I've sometimes
>>> missed a --no-ff option to 'git merge' when working on plain git
>>> repositories; IMHO preserving the 'logical' merge history when the
>>> merge of a topic branch results in a fast-forward can be interesting.
>>>
>> If you really want one, use git commit-tree directly.
>>
> Yeah, that's an option, but --no-ff is somewhat less work ;-)
>
Sure. I just don't see a good use case for it from this yet.
Sam.
^ permalink raw reply
* Re: [PATCH 6/7] Export rerere() and launch_editor().
From: Johannes Schindelin @ 2007-09-18 13:14 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <1190074016669-git-send-email-krh@redhat.com>
Hi,
I see rerere() in the patch, but not launch_editor().
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/7] Clean up stripspace a bit, use strbuf even more.
From: Johannes Schindelin @ 2007-09-18 13:12 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11900740153845-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1001 bytes --]
Hi,
I really like your patch, except for this:
On Mon, 17 Sep 2007, Kristian Høgsberg wrote:
> diff --git a/builtin.h b/builtin.h
> index 03ee7bf..d6f2c76 100644
> --- a/builtin.h
> +++ b/builtin.h
> @@ -7,7 +7,6 @@ extern const char git_version_string[];
> extern const char git_usage_string[];
>
> extern void help_unknown_cmd(const char *cmd);
> -extern size_t stripspace(char *buffer, size_t length, int skip_comments);
> extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
> extern void prune_packed_objects(int);
>
> diff --git a/strbuf.h b/strbuf.h
> index 21fc111..5960637 100644
> --- a/strbuf.h
> +++ b/strbuf.h
> @@ -98,4 +98,6 @@ extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
>
> extern void read_line(struct strbuf *, FILE *, int);
>
> +extern void stripspace(struct strbuf *buf, int skip_comments);
> +
> #endif /* STRBUF_H */
If you do that, you have to move the function "stripspace" to strbuf.c,
too...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] git-apply: fix whitespace stripping
From: J. Bruce Fields @ 2007-09-18 13:12 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86r6kw4aki.fsf@lola.quinscape.zz>
On Tue, Sep 18, 2007 at 10:55:25AM +0200, David Kastrup wrote:
> As far as I can see, this does not really work since it does not
> maintain an idea of a current column.
>
> If you have
>
> abcd<four spaces><tab><four spaces><tab>
>
> then indeed the resulting conversion needs to be <tab><tab><tab>
> whereas with
>
> abc<four spaces><tab><four spaces><tab>
>
> the resulting conversion needs to be just <tab><tab>
Note that this code *only* handles whitespace in the initial indent;
processing stops as soon as it hits anything other than a tab or an
indent.
Given that, I believe the proposed patch is correct. Am I missing
something else?
--b.
^ permalink raw reply
* Re: [PATCH] git-send-email: Add a --cc-nobody option
From: Felipe Balbi @ 2007-09-18 13:01 UTC (permalink / raw)
To: Alex Unleashed; +Cc: git, ae, Felipe Balbi
In-Reply-To: <5e4707340709180550w3211e95fqd9fd648aab8ce78a@mail.gmail.com>
hi,
On 9/18/07, Alex Unleashed <unledev@gmail.com> wrote:
> On 9/18/07, felipebalbi@users.sourceforge.net
> <felipebalbi@users.sourceforge.net> wrote:
> > From: Felipe Balbi <felipe.lima@indt.org.br>
> >
> > This patch adds a --cc-nobody option to avoid sending emails
> > to everybody but the ones listed by --to option.
> >
> > Signed-off-by: Felipe Balbi <felipe.lima@indt.org.br>
>
> I wrote a similar patch a couple months ago, but they differ slightly,
> maybe the code has changed somewhat:
> http://marc.info/?l=git&m=118200193310898&w=2
>
> --cc-nobody sounds better to me.
>
> > } elsif (/^(Cc|From):\s+(.*)$/) {
> > - if (unquote_rfc2047($2) eq $sender) {
> > - next if ($suppress_from);
> > + if (unquote_rfc2047($2)) {
> > + next if ($cc_nobody);
> > + }
> > + elsif (unquote_rfc2047($2) eq $sender) {
> > + next if ($suppress_from|$cc_nobody);
> > }
> > elsif ($1 eq 'From') {
> > $author = unquote_rfc2047($2);
>
> Here you could probably skip the whole branch if you check $cc_nobody
> first of all.
Yeah, I tested this one too but when sending emails I was changing all
those From lines to my address, which means every mail I was sending
the patch would take my authorship.
So it looked better guaranteeing the authorship
>
> > @@ -707,7 +715,7 @@ foreach my $t (@files) {
> > }
> > } else {
> > $message .= $_;
> > - if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
> > + if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc && !$cc_nobody) {
>
> Minor, but almost the same here.
sanity
>
> Alex
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ 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