* Re: [TopGit] Multiple concurrent sets of patches
From: Uwe Kleine-König @ 2009-03-03 19:42 UTC (permalink / raw)
To: Jonas Smedegaard; +Cc: git, pasky, martin f krafft
In-Reply-To: <20090303192221.GV12820@jones.dk>
On Tue, Mar 03, 2009 at 08:22:21PM +0100, Jonas Smedegaard wrote:
> On Tue, Mar 03, 2009 at 02:03:16PM +0100, martin f krafft wrote:
> >also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.1237 +0100]:
> >> It seems to me that TopGit is incapable of handling this. That it can
> >> only handle patchset against a single branch, and if the need arise
> >> for restructuring an additional patchset for e.g. a stable or
> >> oldstable branch, then quilt needs to be used manually anyway.
> >
> >Let me try to understand you: you want TopGit to maintain a single
> >feature branch against two different source branches? How should
> >that work? Could you elaborate a bit so that your needs become a bit
> >more obvious?
>
> Not quite. I want TopGit to maintain multiple feature branches,
> preferrably related.
>
> With "related" I mean that I would like to be able to "fork" a chain of
> interdependent feature branches.
>
> TopGit easily support one chain of branches:
>
> upstream + pristine-tar -> master -> build
>
> I want TopGit to additionally support the following:
>
> upstream + pristine-tar -> stable-master -> stable-build
>
> upstream + pristine-tar -> oldstable-master -> oldstable-build
>
>
> E.g. in addition to TopGit branches t/fix_01 and t/feature_01 I would
> want to fork those branches as t_stable/fix_01 and t_stable/feature_01.
>
>
> I know that I can create all those TopGit branches one by one, but I
> would then need to explicitly declare a list of TopGit branches to apply
> each time I want to (re)generate a quilt patchlist.
For my kernel development I use topgit topic branches that collect
topgit patch branches. Take this dependency graph:
linus/master <- t/armmisc/patch1 <- t/armmisc-master <- t/armmisc-pu
^ ^----t/armmisc/patch2 <--' |
`------t/armmisc/patch3 <----------------------'
So t/armmisc-master collects patches that are ready for upstream, -pu
patches that need some more work.
With etch <- lenny <- squeeze <- sid you could do the same. The only
Consider you have a security fix that is relevant for all
releases starting at lenny. Then you do
tg create t/fixes-lenny/CVE-2009-abcd master-lenny
... apply patch
... fill .topmsg
git commit
git checkout t/fixes-lenny-master
tg depend add t/fixes-lenny/CVE-2009-abcd
tg create t/fixes-squeeze/CVE-2009-abcd master-squeeze t/fixes-etch/CVE-2009-abcd
... no need to apply patch
... cherry-pick .topmsg from t/fixes-lenny/CVE-2009-abcd
git commit
git checkout t/fixes-squeeze-master
tg depend add t/fixes-squeeze/CVE-2009-abcd
And if you notice that etch needs the same fix, you can create
t/fixes-etch/CVE-2009-abcd based on master-etch and then do
git checkout t/fixes-lenny/CVE-2009-abcd
tg depend add t/fixes-etch/CVE-2009-abcd
tatata, I think that's it for packaging.
But this doesn't help me for my kernel problem, because here I don't
have that ordering on releases. I want to manage patches on top of
linux-tip and the ARM tree, but none of these contains the other :-/
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: John Dlugosz @ 2009-03-03 19:36 UTC (permalink / raw)
To: git; +Cc: j.sixt
===Re:===
You cannot expect users to switch the locale. For example, I have to
test
our software with Japanese settings: I *cannot* switch to UTF-8 just
because of git.
Can you set the local codepage per program? (I don't know.) It might
help
here, but it doesn't help in all cases, particularly in certain
pipelines:
===end===
Yes, you can. The code page can be set per thread. The function call
is:
SetThreadLocale (lcid);
where lcid is just 65001 for UTF-8. (The other fields in the LCID are
high-order bits and all zero for no sublanguage and default sort order).
When a thread is created, it starts with the system default thread
locale. So call SetThreadLocale on every thread you create. In
particular, realize that the new thread does not inherit this from the
creating thread.
Meanwhile... the file I/O functions don't use the same code page. The
encoding of file names on a floppy disk or whatnot was historically done
using the "OEM code page", and when a different code page is used for
text editing, that shouldn't break compatibility. So, all functions
exported from Kernel32.dll that accept or return file names uses a
separate setting, and setting the locale as shown above will not affect
it. This might be the source of confusion to those experimenting with
it.
So, also make a call to
SetFileApisToANSI();
This affects the entire process, not just the thread.
So much for specifying UTF-8 file names in Windows. A related issue is
the console input and output of same. I don't know if the sh program
that is part of msys or Cygwin does anything to the console window it is
using, but each console window can have its own code page as well. The
default for 8-bit API (char*'s) is also the OEM character set, not the
so-called ANSI character set that is specified with SetThreadLocale.
I've not experimented with setting this (and restoring it) within a
program invoked in that console. But if you use the 16-bit API for
console I/O, it is not a problem and works regardless of how the user
chose to set it. To make it even more confusing, the console doesn't
respect the UTF-8 setting if the font is not set properly too.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Peter Harris @ 2009-03-03 19:35 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090303185108.GA11278@raven.wolf.lan>
On Tue, Mar 3, 2009 at 1:51 PM, Josef Wolf wrote:
> # work on clones, pull work into git-svn-repos when we're done
> #
> for clone in 1 2 3; do
> (
> cd clone$clone
> git pull --rebase
> for commit in 1 2 3; do
> echo change $clone $commit >>test
> git commit -a -m "commit $clone $commit"
> done
> )
> (cd git-svn-repos; git pull --rebase ../clone$clone)
> done
Um. This has each clone basing their commits on the work of some other
clone. This line, specifically:
> (cd git-svn-repos; git pull --rebase ../clone$clone)
breaks the "git-svn-repos only ever pulls from subversion" model I
suggested elsewhere.
Also, this line says "rebase my changes onto those of ../clone$clone",
which isn't what you want. It will end up rebasing svn commits that
the client didn't have on top of the client's commits, and will break
git-svn's index. Don't use --rebase here.
> # Although we have resolved the conflict, spurious conflicts are
> # propagated to the clones
...and this is because you had clones all merge from each other (via
git-svn-repos) *before* the changes were in svn.
Worse, since the git clients don't know that their work has been
rebased, they can wind up conflicting with themselves too. Which is
why I suggested "git svn dcommit" from each client, not from the
central repository.
This can be made work if you do something more like (untested):
(cd git-svn-repos; git pull ../clone$clone topic-branch;
git svn dcommit)
(cd clone$clone; git checkout master; git pull;
have a human verify that changes to master are correct;
git branch -D topic-branch)
instead of
> (cd git-svn-repos; git pull --rebase ../clone$clone)
ie. throw away each topic branch as you push it to git-svn-repos, and
take the changes that have gone through git-svn back via a pull of
master.
But that starts to look to me like more work for each clone than "git
svn dcommit" - YMMV, of course.
Peter Harris
^ permalink raw reply
* Re: parallel dev. with email
From: Peter Baumann @ 2009-03-03 19:35 UTC (permalink / raw)
To: stoecher; +Cc: git
In-Reply-To: <20090303153141.246620@gmx.net>
On Tue, Mar 03, 2009 at 04:31:41PM +0100, stoecher@gmx.at wrote:
> Hi,
>
> I am new to git and I am wondering what git commands to use for this szenario: two developers without the possibility of sharing a server communicate their changes via email.
>
> This is how far I have come reading the online docu:
> * Each developer can create the diff-info of his commits with
> git format-patch
> * and the other developer can incorporate these changes with
> git am
>
> After creating the patches with format-patch one could set a tag:
> git tag -f patchesDone
> so next time one wants to create patches, this tag can be used as the starting point:
> git format-patch patchesDone..
>
> But what if in the meantime one has incorporated the other developer's changes with git am? Then these changes will also be among the patches created with format-patch. What will happen, if these patches are sent to the other developer, who does not need his own changes again. Will his own changes be silently ignored by git am? Or how else to effectively coordinate the work of two developers with git via email?
>
> thank you,
>
> Wolfgang
[ Disclaimer: It was a *very* long time since I used this; there might
be a better way to use bundles already ]
You could also use 'git bundle' to send your changes. E.g. if you have
all your already released/send patches in master branch and all your
locale changes in private
$ git bundle create mybundle private ^master # not sure if private..master
# will work here
and your friend could to
$ git bundle verify mybundle
$ git fetch mybundle master:localRef
to import the changes. (Pls have a look in the manpage of git bundle,
there are many examples)
-Peter
^ permalink raw reply
* Re: remote branches, and branch names in general
From: Jay Soffian @ 2009-03-03 19:32 UTC (permalink / raw)
To: Jeff King; +Cc: John Dlugosz, Jakub Narebski, git
In-Reply-To: <20090303161117.GB32079@coredump.intra.peff.net>
On Tue, Mar 3, 2009 at 11:11 AM, Jeff King <peff@peff.net> wrote:
> Yes, the "branch" command deals only with creating things in refs/heads,
Unless given -r, in which case it looks in refs/remotes, or -a, in
which case it looks in refs/heads and refs/remotes. :-)
> which are your local branches (similarly, "git tag" will only deal with
> stuff in refs/tags). So "git branch origin/foo" will make a ref
> "refs/heads/origin/foo", and "git branch -d origin/foo" will delete
> "refs/heads/origin/foo", not "refs/remotes/origin/foo".
For the latter, use git branch -d -r origin/foo. I'm not sure whether
-r is usable when creating a branch, I haven't tried.
j.
^ permalink raw reply
* Re: move files between disparate repos and maintain version history
From: Jeff King @ 2009-03-03 19:27 UTC (permalink / raw)
To: David Copeland; +Cc: git
In-Reply-To: <f95d47890903031008s36873f6ex94c7096f79cd6de@mail.gmail.com>
On Tue, Mar 03, 2009 at 01:08:17PM -0500, David Copeland wrote:
> The patch file looks correct. I'm wondering if this is a result of
> both repos being connected to svn?
>
> my process was:
>
> - format patch
> - go to other repo
> - git svn rebase
> - apply patch
> - git svn dcommit
>
> Could dcommit change the dates since, to svn, they are appear as
> commits right now?
I know very little about git-svn. But you could test your theory by
checking the dates between the penultimate and ultimate steps.
-Peff
^ permalink raw reply
* Re: [PATCH] git-clone.txt: document that pushing from a shallow clone may work
From: Jay Soffian @ 2009-03-03 19:27 UTC (permalink / raw)
To: Adeodato Simó
Cc: Johannes Sixt, git, gitster, Mikael Magnusson, Joey Hess
In-Reply-To: <20090303120856.GB15003@chistera.yi.org>
On Tue, Mar 3, 2009 at 7:08 AM, Adeodato Simó <dato@net.com.org.es> wrote:
> Well, I don't know if the set of cases where it'll work can be defined
> in detail to a point where it is useful. If it is, then sure, let's do
> it.
>
> My point is that if it will work in some cases, then the documentation
> should *acknowledge that fact*, because else people will assume the
> documentation is wrong, and believe it is intended to work, which is not
> the case.
Wy not just say "pushing into a shallow repository is not supported"
instead of "pushing into a shallow repository won't work."
j.
^ permalink raw reply
* Re: [TopGit] Multiple concurrent sets of patches
From: Jonas Smedegaard @ 2009-03-03 19:22 UTC (permalink / raw)
To: git; +Cc: pasky, u.kleine-koenig, martin f krafft
In-Reply-To: <20090303130316.GA17702@piper.oerlikon.madduck.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Mar 03, 2009 at 02:03:16PM +0100, martin f krafft wrote:
>also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.1237 +0100]:
>> It seems to me that TopGit is incapable of handling this. That it can
>> only handle patchset against a single branch, and if the need arise
>> for restructuring an additional patchset for e.g. a stable or
>> oldstable branch, then quilt needs to be used manually anyway.
>
>Let me try to understand you: you want TopGit to maintain a single
>feature branch against two different source branches? How should
>that work? Could you elaborate a bit so that your needs become a bit
>more obvious?
Not quite. I want TopGit to maintain multiple feature branches,
preferrably related.
With "related" I mean that I would like to be able to "fork" a chain of
interdependent feature branches.
TopGit easily support one chain of branches:
upstream + pristine-tar -> master -> build
I want TopGit to additionally support the following:
upstream + pristine-tar -> stable-master -> stable-build
upstream + pristine-tar -> oldstable-master -> oldstable-build
E.g. in addition to TopGit branches t/fix_01 and t/feature_01 I would
want to fork those branches as t_stable/fix_01 and t_stable/feature_01.
I know that I can create all those TopGit branches one by one, but I
would then need to explicitly declare a list of TopGit branches to apply
each time I want to (re)generate a quilt patchlist.
Perhaps what I really am looking for here is something like "tg tag":
git checkout t/fix_01
tg tag t/fix_01 master
git checkout -b t_stable/fix_01 t/fix_01
tg tag -d master
tg tag stable
git checkout stable_build
./debian/rules tg-export tags=stable
...or perhaps this is not relevant upstream to TopGit at all but only to
your packaging of a "tg-export" rule?
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmtg20ACgkQn7DbMsAkQLhQGQCfQjtfJzzQUu6B0qywpkmxmdGp
66oAnjEtR2Dc/zJ+lMoP3TD3jy1pr1s9
=MwTs
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: move files between disparate repos and maintain version history
From: Peter Baumann @ 2009-03-03 19:22 UTC (permalink / raw)
To: David Copeland; +Cc: git
In-Reply-To: <f95d47890903031008s36873f6ex94c7096f79cd6de@mail.gmail.com>
On Tue, Mar 03, 2009 at 01:08:17PM -0500, David Copeland wrote:
> The patch file looks correct. I'm wondering if this is a result of
> both repos being connected to svn?
>
> my process was:
>
> - format patch
> - go to other repo
> - git svn rebase
This will change the date of commits already in svn because it uses
git rebase (with all its problems, see its manpage)
> - apply patch
> - git svn dcommit
>
> Could dcommit change the dates since, to svn, they are appear as
> commits right now?
>
> Dave
>
> On Tue, Mar 3, 2009 at 12:18 PM, Jeff King <peff@peff.net> wrote:
> > On Tue, Mar 03, 2009 at 11:58:42AM -0500, David Copeland wrote:
> >
> >> The first option worked, insomuch the history of diffs is preserved,
> >> but the dates are all today.
> >
> > That's odd. It works fine here. Can you confirm that the correct dates
> > in the "patches" file (i.e., the output of format-patch)? What are you
> > using to look at the patches? Note that gitk will show you both the
> > "committer" and the "author" fields. The "author" field should have the
> > original author and time of the patch, but the "committer" will be you,
> > today.
> >
> >> The second option was a little over my head; is the idea there that
> >> you are setting up a branch that has ONLY the files I care about (with
> >> all their history), and then I pull from the other repo as if they are
> >> related? That seems like it might preserve the dates...
> >
> > Yes, that is exactly what is happening in the second example.
> >
> > -Peff
^ permalink raw reply
* Re: [Orinoco-users] linux-firmware binary corruption with gitweb
From: Dave @ 2009-03-03 18:59 UTC (permalink / raw)
To: Pavel Roskin, git; +Cc: linux-kernel, orinoco-users, dwmw2
In-Reply-To: <1235886467.3195.15.camel@mj>
Adding the git mailing list.
Pavel Roskin wrote:
> On Sat, 2009-02-28 at 19:24 +0000, Dave wrote:
>> I'm aware of at least a couple users of orinoco who have picked up
>> corrupt firmware# from the linux-firmware tree*.
>>
>> I've verified that the firmware in the repository itself is correct.
>>
>> It appears that downloading the file using the blob/raw links from
>> gitweb causes the corruption (0xc3 everywhere). At least it does with
>> firefox.
>
> I can confirm the problem with Firefox 3.0.6. But it's not "0xc3
> everywhere". The corrupted file is a result of recoding from iso-8859-1
> to utf-8. The correct agere_sta_fw.bin is 65046 bytes long. The
> corrupted agere_sta_fw.bin is 89729 bytes long.
>
> There is a way to recode the original binary with GNU recode:
> recode utf8..iso8859-1 agere_sta_fw.bin
>
> wget 1.11.4 also gets a corrupted file 89729 bytes long.
>
> curl 7.18.2 also get the corrupted file:
>
> My strong impression is that the recoding takes place on the server. I
> think the bug should be reported to the gitweb maintainers unless it a
> local breakage on the kernel.org site.
Thanks Pavel.
I just did a quick scan of the gitweb README - is this an issue with the
$mimetypes_file or $fallback_encoding configurations variables?
Regards,
Dave.
#<http://marc.info/?l=orinoco-users&m=123411762524637>
*<http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=shortlog>
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-03-03 18:51 UTC (permalink / raw)
To: git
In-Reply-To: <49A97B7A.8010005@drmicha.warpmail.net>
On Sat, Feb 28, 2009 at 06:59:22PM +0100, Michael J Gruber wrote:
> Josef Wolf venit, vidit, dixit 27.02.2009 23:05:
> > On Fri, Feb 27, 2009 at 06:45:44PM +0100, Michael J Gruber wrote:
> >> Josef Wolf venit, vidit, dixit 27.02.2009 18:12:
> >>> On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:
> >>>> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:
> >
> > [ ... ]
> >>> (cd git-svn-repos; git pull ../clone1)
> >> Gives you 1-2-3-4
> >>
> >>> (cd git-svn-repos; git svn rebase)
> >> Does nothing here (but is good practice)
> >>
> >>> (cd git-svn-repos; git svn dcommit)
> >> Creates 2-3-4 on the svn side. *Then rebases* your master, which creates
> >> 1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id).
> >
> > So the sha1 is not preserved when it goes through svn?
>
> No. Once your commits come back from svn through git-svn they have an
> additional line in the commit. Also, the commit time time will be
> different, and the author name might be depending on your name remapping.
But what prevents this new commit from being thrown back to svn again,
and looping over and over again?
For some reason, I keep getting conflicts. And the most annoying
part is that even if I resolve the conflict in git-svn-repos, it
gets propagated as a (spurious) conflict down to all the clones.
Here's the recipe:
(
set -ex
# create test directory
#
TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`
rm -rf $TESTDIR
mkdir -p $TESTDIR
cd $TESTDIR
SUBVERSION_REPOS=file://`pwd`/subversion-repos
# create subversion repos with some history
#
svnadmin create subversion-repos
svn -m "create standard layout" mkdir \
$SUBVERSION_REPOS/trunk \
$SUBVERSION_REPOS/branches \
$SUBVERSION_REPOS/tags
svn co $SUBVERSION_REPOS/trunk subversion-wc
echo change1 >>subversion-wc/test
svn add subversion-wc/test
svn ci -m "commit 0" subversion-wc
# create git-svn-repos
#
git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos
(cd git-svn-repos; git svn fetch)
# create some clones
#
git clone git-svn-repos clone1
git clone git-svn-repos clone2
git clone git-svn-repos clone3
# work on clones, pull work into git-svn-repos when we're done
#
for clone in 1 2 3; do
(
cd clone$clone
git pull --rebase
for commit in 1 2 3; do
echo change $clone $commit >>test
git commit -a -m "commit $clone $commit"
done
)
(cd git-svn-repos; git pull --rebase ../clone$clone)
done
# commit from svn
#
( cd subversion-wc; echo change s >>test; svn ci -m "commit s")
# git-svn-rebase gives us a conflict
#
( cd git-svn-repos; git svn rebase )
# which we immediately resolve
#
(
cd git-svn-repos
(
echo change1
echo change s
echo change 1 1
) >test
git add test
git rebase --continue
)
(cd git-svn-repos; git svn dcommit)
# Although we have resolved the conflict, spurious conflicts are
# propagated to the clones
#
for clone in 1 2 3; do
( cd clone$clone ; git pull --rebase)
done
)
^ permalink raw reply
* Re: [PATCH] Documentation/git-archive.txt: Note attributes
From: Roy Lee @ 2009-03-03 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: roylee, git
In-Reply-To: <7vab82bgxv.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Wed, Mar 4, 2009 at 2:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Please add a sign-off. What the patch text says looks perfect, even
> though the lines are too long and would better be rewrapped and the lines
> under ATTRIBUTES must match the length of the word it underlines (this is
> text marked-up with asciidoc, not just freeform).
>
> Thanks.
>
Thanks for the comment. Here's the revised patch.
Regards,
Roy
[-- Attachment #2: 0001-Documentation-git-archive.txt-Note-attributes.patch --]
[-- Type: application/octet-stream, Size: 1471 bytes --]
From 272054237f204619ed934b764db485db97faa5c9 Mon Sep 17 00:00:00 2001
From: Roy Lee <roylee17@gmail.com>
Date: Wed, 4 Mar 2009 00:49:29 +0800
Subject: [PATCH] Documentation/git-archive.txt: Note attributes
Signed-off-by: Roy Lee <roylee17@gmail.com>
---
Documentation/git-archive.txt | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 41cbf9c..5b3eb12 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -88,6 +88,18 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) for
details.
+ATTRIBUTES
+----------
+
+export-ignore::
+ Files and directories with the attribute export-ignore won't be
+ added to archive files. See linkgit:gitattributes[5] for details.
+
+export-subst::
+ If the attribute export-subst is set for a file then git will
+ expand several placeholders when adding this file to an archive.
+ See linkgit:gitattributes[5] for details.
+
EXAMPLES
--------
git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
@@ -110,6 +122,11 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs
Put everything in the current head's Documentation/ directory
into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
+
+SEE ALSO
+--------
+linkgit:gitattributes[5]
+
Author
------
Written by Franck Bui-Huu and Rene Scharfe.
--
1.6.1.3
^ permalink raw reply related
* Re: [PATCH] Make git-clone respect branch.autosetuprebase
From: Junio C Hamano @ 2009-03-03 18:48 UTC (permalink / raw)
To: pknotz; +Cc: git
In-Reply-To: <1236105352-21335-1-git-send-email-pknotz@sandia.gov>
pknotz@sandia.gov writes:
> diff --git a/builtin-clone.c b/builtin-clone.c
> index c338910..f547267 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -360,6 +360,14 @@ static void install_branch_config(const char *local,
> strbuf_reset(&key);
> strbuf_addf(&key, "branch.%s.merge", local);
> git_config_set(key.buf, remote);
> + switch (autorebase) {
> + case AUTOREBASE_REMOTE:
> + case AUTOREBASE_ALWAYS:
> + strbuf_reset(&key);
> + strbuf_addf(&key, "branch.%s.rebase", local);
> + git_config_set(key.buf, "true");
> + printf("Default branch '%s' will rebase on pull.\n", local);
> + }
> strbuf_release(&key);
> }
I think this whole function should be moved to to branch.c to be usable
across "git checkout -b", "git branch" and "git clone", and make the two
existing callers in builtin-clone.c and setup_tracking() in branch.c call
it. "git checkout -b" already shares the same codepath with "git branch",
and you would allow "git clone" to be in the family. That would help
supporting new tracking options without having to maintain more than one
copy of the code.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Shawn O. Pearce @ 2009-03-03 18:41 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <20090303092301.GE32284@mit.edu>
Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Mar 03, 2009 at 12:30:46AM -0800, Junio C Hamano wrote:
> > Jeff King <peff@peff.net> writes:
> >
> > > But I think that coincides with what I was trying to say in my original
> > > response to the series, which is "this issue is complex, and we need to
> > > hear from the people who would really want this exactly what it is they
> > > want".
> >
> > And we haven't heard from them at all, unless you and/or Shawn are
> > interested. After all we may not have to worry about this at all ;-)
>
> Junio, I assume you saw Scott James Remnant blog posts, "Git Sucks"?
>
> http://www.netsplit.com/2009/02/17/git-sucks/
Funny, this very blog post is talking about why I think remote
creation should be under git push, not "git init --remote".
IMHO, maybe we also should change the error message that receive-pack
produces when the path its given isn't a Git repository. Its really
not very human friendly to say "unable to chdir or not a git archive".
Hell, we don't even call them archives, we call them repositories.
--
Shawn.
^ permalink raw reply
* [PATCH] Make git-clone respect branch.autosetuprebase
From: pknotz @ 2009-03-03 18:35 UTC (permalink / raw)
To: git; +Cc: Pat Notz
From: Pat Notz <pknotz@sandia.gov>
When git-clone creates an initial branch it was not
checking the branch.autosetuprebase configuration
option (which may exist in ~/.gitconfig).
Signed-off-by: Pat Notz <pknotz@sandia.gov>
---
builtin-clone.c | 8 ++++++++
t/t5601-clone.sh | 14 ++++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index c338910..f547267 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -360,6 +360,14 @@ static void install_branch_config(const char *local,
strbuf_reset(&key);
strbuf_addf(&key, "branch.%s.merge", local);
git_config_set(key.buf, remote);
+ switch (autorebase) {
+ case AUTOREBASE_REMOTE:
+ case AUTOREBASE_ALWAYS:
+ strbuf_reset(&key);
+ strbuf_addf(&key, "branch.%s.rebase", local);
+ git_config_set(key.buf, "true");
+ printf("Default branch '%s' will rebase on pull.\n", local);
+ }
strbuf_release(&key);
}
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 44793f2..0f8b43c 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -159,4 +159,18 @@ test_expect_success 'clone a void' '
test_cmp target-6/.git/config target-7/.git/config
'
+test_expect_success 'clone respects global branch.autosetuprebase' '
+ HOME="`pwd`" &&
+ export HOME &&
+ test_config="$HOME"/.gitconfig &&
+ unset GIT_CONFIG_NOGLOBAL &&
+ git config -f "$test_config" branch.autosetuprebase remote &&
+ rm -fr dst &&
+ git clone src dst &&
+ cd dst &&
+ expected="ztrue" &&
+ actual="z$(git config branch.master.rebase)" &&
+ test $expected = $actual
+'
+
test_done
--
1.6.1.2
^ permalink raw reply related
* Re: [PATCH] Documentation/git-archive.txt: Note attributes
From: Junio C Hamano @ 2009-03-03 18:27 UTC (permalink / raw)
To: roylee; +Cc: git, Roy Lee
In-Reply-To: <1236099168-20231-1-git-send-email-roylee@andestech.com>
roylee@andestech.com writes:
> From: Roy Lee <roylee17@gmail.com>
>
> ---
Please add a sign-off. What the patch text says looks perfect, even
though the lines are too long and would better be rewrapped and the lines
under ATTRIBUTES must match the length of the word it underlines (this is
text marked-up with asciidoc, not just freeform).
Thanks.
> Documentation/git-archive.txt | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
> index 41cbf9c..96f5424 100644
> --- a/Documentation/git-archive.txt
> +++ b/Documentation/git-archive.txt
> @@ -88,6 +88,17 @@ tar.umask::
> archiving user's umask will be used instead. See umask(2) for
> details.
>
> +ATTRIBUTES
> +----------------
> +
> +export-ignore::
> + Files and directories with the attribute export-ignore won't be added to archive files.
> + See linkgit:gitattributes[5] for details.
> +
> +export-subst::
> + If the attribute export-subst is set for a file then git will expand several placeholders when adding this file
> + to an archive. See linkgit:gitattributes[5] for details.
> +
> EXAMPLES
> --------
> git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
> @@ -110,6 +121,11 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs
> Put everything in the current head's Documentation/ directory
> into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
>
> +
> +SEE ALSO
> +--------
> +linkgit:gitattributes[5]
> +
> Author
> ------
> Written by Franck Bui-Huu and Rene Scharfe.
> --
> 1.6.1.3
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: John Dlugosz @ 2009-03-03 18:25 UTC (permalink / raw)
To: git; +Cc: peter
===Re:===
The other way would be to keep the char* APIs but convert to the Windows
locale encoding ("ANSI codepage"), but that will break horribly as not
all
file names that can be used on a file system can be represented as such.
===end===
Actually, UTF-8 is a valid code page on Windows. The code page ID is
65001. So, if you set the process code page to that, =and= set the file
system API's code page to follow rather than using the OEM code page
(the default), it should work just fine.
Also, there is a national code page that =will= represent all file names
on the systems and is supported: That is the Chinese GB18030, code page
54936. That has every character that Unicode does, just encoded
differently to be forward compatible with GBK. That is fully supported
by windows, as it is required by law to sell in Chinese markets.
Let me know if I can be of help. I know character set stuff and Win32
fairly well.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH] doc: clarify how -S works
From: Junio C Hamano @ 2009-03-03 18:24 UTC (permalink / raw)
To: John Tapsell; +Cc: Jeff King, Peter Valdemar Mørch (Lists), git
In-Reply-To: <43d8ce650903030939u73f09171uf4041b6d9824b698@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> 2009/3/3 Jeff King <peff@peff.net>:
>> On Tue, Mar 03, 2009 at 08:42:12AM -0800, Junio C Hamano wrote:
>>
>>> In retrospect, because --pickaxe was designed primarily for Porcelain use,
>>> it was a mistake for it to have taken a short-and-sweet -S synonym.
>>
>> Hmm. I actually like the pickaxe behavior and find it useful for
>> searching. IOW, I consider it a porcelain feature, just perhaps not the
>> one that some people are expecting.
>>
>>> > -S<string>::
>>> > - Look for differences that contain the change in <string>.
>>> > + Look for differences that introduce or remove an instance of
>>> > + <string>. Note that this is different than the string simply
>>> > + appearing in diff output; see the 'pickaxe' entry in
>>> > + linkgit:gitdiffcore[7] for more details.
>>>
>>> Look for differences that change the number of occurrences of <string>?
>>
>> Yes, that is technically correct. I was trying to find a wording that
>> was a little less "this is literally what it does" and more "this is
>> what you might find it useful for".
>
> Is there any way to have an option to also match any line containing
> the string?
Patches welcome. I've already outlined what you need to do.
I think it can be called -G (short for --grep-diff), if --search cannot be
used because "-s" is unavailable.
^ permalink raw reply
* Re: [PATCH v3] send-email: add --confirm option and configuration setting
From: Jay Soffian @ 2009-03-03 18:18 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, git, Nanako Shiraishi, Paul Gortmaker
In-Reply-To: <36ca99e90903031005g3d54436cs486133a340c1eec1@mail.gmail.com>
On Tue, Mar 3, 2009 at 1:05 PM, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>
> Just to clarify: A user who runs a --dry-run before every sending
> (like me) would check the Cc list anyway (like me), so he either would
> have sendmail.confirm=never in the config, so that he will not
> bothered by send-email while sending or he sees some Cc's that he
> don't want and can remove them in the sending process.
Correct. This confirm addition was motivated by new users who do not know about
--dry-run and are surprised when their email is sent to unintended recipients.
If you always use --dry-run, and don't want to be prompted when you actually
send, then setting sendemail.confirm=never is what you want.
> Ok, than I'm fine with this.
Phew. :-)
j.
^ permalink raw reply
* Re: move files between disparate repos and maintain version history
From: David Copeland @ 2009-03-03 18:08 UTC (permalink / raw)
To: git
In-Reply-To: <20090303171835.GB454@coredump.intra.peff.net>
The patch file looks correct. I'm wondering if this is a result of
both repos being connected to svn?
my process was:
- format patch
- go to other repo
- git svn rebase
- apply patch
- git svn dcommit
Could dcommit change the dates since, to svn, they are appear as
commits right now?
Dave
On Tue, Mar 3, 2009 at 12:18 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 03, 2009 at 11:58:42AM -0500, David Copeland wrote:
>
>> The first option worked, insomuch the history of diffs is preserved,
>> but the dates are all today.
>
> That's odd. It works fine here. Can you confirm that the correct dates
> in the "patches" file (i.e., the output of format-patch)? What are you
> using to look at the patches? Note that gitk will show you both the
> "committer" and the "author" fields. The "author" field should have the
> original author and time of the patch, but the "committer" will be you,
> today.
>
>> The second option was a little over my head; is the idea there that
>> you are setting up a branch that has ONLY the files I care about (with
>> all their history), and then I pull from the other repo as if they are
>> related? That seems like it might preserve the dates...
>
> Yes, that is exactly what is happening in the second example.
>
> -Peff
>
^ permalink raw reply
* Re: [PATCH v3] send-email: add --confirm option and configuration setting
From: Bert Wesarg @ 2009-03-03 18:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git, Nanako Shiraishi, Paul Gortmaker
In-Reply-To: <7vvdqqblij.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 3, 2009 at 17:48, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> On Tue, Mar 3, 2009 at 6:54 AM, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>>> On Tue, Mar 3, 2009 at 05:52, Jay Soffian <jaysoffian@gmail.com> wrote:
>>>> diff --git a/git-send-email.perl b/git-send-email.perl
>>>> index adf7ecb..57127aa 100755
>>>> --- a/git-send-email.perl
>>>> +++ b/git-send-email.perl
>>>> @@ -837,6 +837,37 @@ X-Mailer: git-send-email $gitversion
>>>> unshift (@sendmail_parameters,
>>>> '-f', $raw_from) if(defined $envelope_sender);
>>>>
>>>> + if ($needs_confirm && !$dry_run) {
>>> So, the output is now differnt with and without --dry-run?
>>
>> There doesn't seem to be any point in having the user confirm before
>> sending the message if the message is not actually going to be sent.
>> Am I missing something?
>
> I do not think you are missing anything.
>
> IIRC, the --dry-run mode shows more clearly to whom you would be CC'ing
> the messages; in other words, the behaviour would be different, but it
> gives an uninteractive way to confirm, and not pausing for confirmation is
> a good thing.
>
Just to clarify: A user who runs a --dry-run before every sending
(like me) would check the Cc list anyway (like me), so he either would
have sendmail.confirm=never in the config, so that he will not
bothered by send-email while sending or he sees some Cc's that he
don't want and can remove them in the sending process.
Ok, than I'm fine with this.
Regards,
Bert
^ permalink raw reply
* Re: [PATCH] doc: clarify how -S works
From: Jeff King @ 2009-03-03 17:57 UTC (permalink / raw)
To: John Tapsell; +Cc: Junio C Hamano, Peter Valdemar Mørch (Lists), git
In-Reply-To: <43d8ce650903030939u73f09171uf4041b6d9824b698@mail.gmail.com>
On Tue, Mar 03, 2009 at 05:39:38PM +0000, John Tapsell wrote:
> > Yes, that is technically correct. I was trying to find a wording that
> > was a little less "this is literally what it does" and more "this is
> > what you might find it useful for".
>
> Is there any way to have an option to also match any line containing
> the string? That might be the best way to document it, as well as
> being very useful:
>
> -s<string>
> Look for any additions, removals or changes in any line containing <string>
> -S<string>
> Look only for any additions or removals of the <string> in any line
Yes, that would be possible (though it is still not foolproof against
moves, as I mentioned elsewhere), and I think it would be simple to
explain the two together. It just needs somebody to code it.
Unfortunately "-s" is already taken for "no output".
-Peff
^ permalink raw reply
* Re: More on "fast foward"
From: Johannes Schindelin @ 2009-03-03 17:53 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F0769A@EXCHANGE.trad.tradestation.com>
Hi,
On Tue, 3 Mar 2009, John Dlugosz wrote:
> After I merged the release fixes back into the development branch, I was
> surprised that push complained that it was not fast-forward. I thought
> someone must have added something since I looked, but no, my repository
> matches exactly. My new dev branch label is the immediate descendant of
> the old one. My new node has another ancestor as well, but so what? The
> same changes, not recorded as a merge, would work without complaint.
I can only assume that something went wrong with the merge. To be
absolutely sure that your new tip of the branch is a descendant of the
current tip on the remote side, do this:
$ git show-branch $BRANCH $(git ls-remote $REMOTE $BRANCH)
where $BRANCH and $REMOTE are determined by your push command which should
look something like this:
$ git push $REMOTE $BRANCH
The show-branch command should show you what Git assumes happened on both
branches (the local and the remote one) since the branch point.
Ciao,
Dscho
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-03 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Reece Dunn, git
In-Reply-To: <20090303173417.GA1243@coredump.intra.peff.net>
Hi,
On Tue, 3 Mar 2009, Jeff King wrote:
> On Tue, Mar 03, 2009 at 06:27:27PM +0100, Johannes Schindelin wrote:
>
> > I am interested in reading Reece's short stories, though.
>
> I can only hope that they're git-themed (Linus fan-fiction?).
No, that is an intended purpose of Git. To worship Linus.
Thus, it would not qualify.
Ciao,
Dscho
^ permalink raw reply
* More on "fast foward"
From: John Dlugosz @ 2009-03-03 17:45 UTC (permalink / raw)
To: git
After I merged the release fixes back into the development branch, I was
surprised that push complained that it was not fast-forward. I thought
someone must have added something since I looked, but no, my repository
matches exactly. My new dev branch label is the immediate descendant of
the old one. My new node has another ancestor as well, but so what?
The same changes, not recorded as a merge, would work without complaint.
The glossary states, "A fast-forward is a special type of merge where
you have a revision and you are "merging" another branch's changes that
happen to be a descendant of what you have. In such these cases, you do
not make a new merge commit but instead just update to his revision.
This will happen frequently on a tracking branch of a remote
repository." Why did that not work this time?
I'm especially worried about this because it means that topic branches
merged back to the development core when ready would not be a fast
forward, and the "ordinary users" should not force pushes.
What am I missing?
--John
(please excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ 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