* Re: Usability of git stash
From: Anders Melchiorsen @ 2008-10-18 9:26 UTC (permalink / raw)
To: Brandon Casey; +Cc: David Kastrup, git
In-Reply-To: <vCcONcOJu3QKQyRgPdT5Dws3F2P25RNAFOgM5GX6FWWKJe40papCRw@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> In exchange for allowing new users to stub their toe on new commands, the
> work flow of more experienced users is made a little easier.
I wonder whether experienced users even use stash a lot. Personally,
after getting my head around the DAG, and thus getting more
comfortable with git reset, I tend to make "WIP" commits instead.
After having used "git stash clear" at a bad time once, I am wary of
stashing work that I actually want to keep. I prefer workflows where
my mistakes can be (easily) corrected.
The primary thing that stash does for me is preserve the index state.
Unfortunately, --index is not default for stash apply, so I often
forget it.
Sometimes, I also want stash to store away changes to untracked files
(to get a clean working directory), but that is not possible.
Maybe I just don't quite understand what git stash is about ...
Anders.
^ permalink raw reply
* Re: [PATCH 1/3] add alloc_ref_with_prefix()
From: Bert Wesarg @ 2008-10-18 9:27 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <48F9A054.4010703@lsrfire.ath.cx>
On Sat, Oct 18, 2008 at 10:37, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> In three cases in remote.c, a "raw" ref is allocated using alloc_ref()
> and then its is constructed using sprintf(). Clean it up by adding a
> helper function, alloc_ref_with_prefix(), which creates a composite
> name. Use it in alloc_ref_from_str(), too, as it simplifies the code.
>
> Open code alloc_ref() in alloc_ref_with_prefix(), as the former is
> going to be removed in the patch after the next.
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> ---
> remote.c | 32 ++++++++++++++++----------------
> 1 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index 8a04066..98cbcf9 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -749,6 +749,16 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec)
> return -1;
> }
>
> +static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
> + const char *name)
> +{
> + size_t len = strlen(name);
> + struct ref *ref = xcalloc(1, sizeof(struct ref) + prefixlen + len + 1);
> + memcpy(ref->name, prefix, prefixlen);
> + memcpy(ref->name + prefixlen, name, len);
Where does you \0-terminate the string?
Regards
Bert
^ permalink raw reply
* Re: [msysGit] Re: Weird filename encoding issue
From: Robin Rosenberg @ 2008-10-18 9:35 UTC (permalink / raw)
To: msysgit, agladysh; +Cc: Johannes Sixt, git
In-Reply-To: <c6c947f60810172322o12beeb80xfd39b551b0db7c99@mail.gmail.com>
lördagen den 18 oktober 2008 08.22.24 skrev Alexander Gladysh:
> 2. Now I have one such file. I'm managing my repo on OS X, and have no
> access to other machines right now. How can I create commit that
> renames the file? Git GUI manages to create commit that adds the
> renamed file, but does not delete old one.
Rename the file and add it. Then git add -u to remove the old name and commit.
-- tobin
^ permalink raw reply
* Re: [PATCH 1/3] add alloc_ref_with_prefix()
From: René Scharfe @ 2008-10-18 9:39 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <36ca99e90810180227u367783f6vc3b7af0176f6df06@mail.gmail.com>
>> +static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
>> + const char *name)
>> +{
>> + size_t len = strlen(name);
>> + struct ref *ref = xcalloc(1, sizeof(struct ref) + prefixlen + len + 1);
>> + memcpy(ref->name, prefix, prefixlen);
>> + memcpy(ref->name + prefixlen, name, len);
> Where does you \0-terminate the string?
xcalloc() calls calloc(), which zeroes the memory.
René
^ permalink raw reply
* Re: Archiving tags/branches?
From: SZEDER Gábor @ 2008-10-18 10:23 UTC (permalink / raw)
To: Pete Harlan; +Cc: git
In-Reply-To: <48F93F52.4070506@pcharlan.com>
Hi Pete,
On Fri, Oct 17, 2008 at 06:43:46PM -0700, Pete Harlan wrote:
> If I wanted to archive those, it looks like this would work:
>
> mkdir .git/refs/archived-tags
> cp -a .git/refs/tags/* .git/refs/archived-tags
> git tag -d <tag-to-hide> # repeat as necessary
>
> I can then maintain a short list of tags that currently interest me, but
> am guaranteed not to lose old branches (say) referenced by those tags.
>
> Is there a reason this won't work?
Yes:
$ git --version
git version 1.6.0.2.574.g7d0e0
$ git init
Initialized empty Git repository in /home/szeder/tmp/git/archive/.git/
$ echo 1 >foo
$ git add foo
$ git commit -m bar
Created initial commit 0c92489: bar
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ git tag t
$ git update-ref refs/archived-tags/t t
$ git tag -d t
Deleted tag 't'
$ cat .git/refs/archived-tags/t
0c92489da6ec6dfd9875eb590d820fcceb01829b
$ git gc
Counting objects: 3, done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 0 (delta 0)
$ cat .git/refs/archived-tags/t
cat: .git/refs/archived-tags/t: No such file or directory
So, if you put any tags or branches under refs/whatever-non-standard/,
then it gets deleted when you gc (or when gc is run automatically).
I don't know whether this behaviour is intentional or not, but I have
experienced this the hard way recently.
Regards,
Gábor
^ permalink raw reply
* Re: Archiving tags/branches?
From: Johan Herland @ 2008-10-18 11:15 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor, Pete Harlan
In-Reply-To: <20081018102345.GA3749@neumann>
On Saturday 18 October 2008, SZEDER Gábor wrote:
> Hi Pete,
>
> On Fri, Oct 17, 2008 at 06:43:46PM -0700, Pete Harlan wrote:
> > If I wanted to archive those, it looks like this would work:
> >
> > mkdir .git/refs/archived-tags
> > cp -a .git/refs/tags/* .git/refs/archived-tags
> > git tag -d <tag-to-hide> # repeat as necessary
> >
> > I can then maintain a short list of tags that currently interest me,
> > but am guaranteed not to lose old branches (say) referenced by those
> > tags.
> >
> > Is there a reason this won't work?
>
> Yes:
>
> [...]
>
> So, if you put any tags or branches under refs/whatever-non-standard/,
> then it gets deleted when you gc (or when gc is run automatically).
>
> I don't know whether this behaviour is intentional or not, but I have
> experienced this the hard way recently.
Go have a look in .git/packed-refs. Then have a read through
git-pack-refs(1).
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-18 11:59 UTC (permalink / raw)
To: Junio C Hamano, git
When source git repository has extension ".git" like in "MyRepo.git"
"git fetch" will drop ".git" extension and refer to it as "MyRepo".
Example:
sh$ git fetch -v ../MyRepo.git master
From ../MyRepo
* branch master -> FETCH_HEAD
sh$ cat .git/FETCH_HEAD
6eb10bd105f2ef7f64c595100c0a850c5b3cfeb9 branch 'master' of ../MyRepo
Please, note that "git fetch" writes "../MyRepo" instead of "../MyRepo.git"
My workflow makes it convenient to have two distinct repositories
(1) "MyRepo" => where I work daily (WIP)
(2) "MyRepo.git" => --bare repository accessible to others. "MyRepo"
pushes ready changes to "MyRepo.git"
Dropping ".git" extension causes confusion between these two quite
similarly named repositories.
This problem can be easily solved by the patch below that removes the
code that strips off ".git" extension.
--Leo--
----8<-------------------
builtin-fetch--tool.c | 2 --
builtin-fetch.c | 2 --
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index 7460ab7..5d0b95f 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -160,8 +160,6 @@ static int append_fetch_head(FILE *fp,
for (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)
;
remote_len = i + 1;
- if (4 < i && !strncmp(".git", remote + i - 3, 4))
- remote_len = i - 3;
note_len = 0;
if (*what) {
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..28123a5 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -348,8 +348,6 @@ static int store_updated_refs(const char *url,
const char *remote_name,
for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)
;
url_len = i + 1;
- if (4 < i && !strncmp(".git", url + i - 3, 4))
- url_len = i - 3;
note_len = 0;
if (*what) {
^ permalink raw reply related
* Re: [PATCH 1/3] add alloc_ref_with_prefix()
From: Bert Wesarg @ 2008-10-18 12:07 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <48F9AECA.3020606@lsrfire.ath.cx>
On Sat, Oct 18, 2008 at 11:39, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>> +static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
>>> + const char *name)
>>> +{
>>> + size_t len = strlen(name);
>>> + struct ref *ref = xcalloc(1, sizeof(struct ref) + prefixlen + len + 1);
>>> + memcpy(ref->name, prefix, prefixlen);
>>> + memcpy(ref->name + prefixlen, name, len);
>> Where does you \0-terminate the string?
>
> xcalloc() calls calloc(), which zeroes the memory.
So, you write the memory range twice, just for the last \0?
Bert
>
> René
>
^ permalink raw reply
* [Q] submitting patches from gmail
From: Leo Razoumov @ 2008-10-18 12:08 UTC (permalink / raw)
To: git
Hi Everyone,
I wonder what is the preferred way to submit patches from a gmail account.
Google mail auto wraps long lines and there is no way to change this setting.
Safe way would be to use attachments. Are they allowed on git mailing list?
Thanks,
--Leo--
^ permalink raw reply
* Re: [Gitk Patch 0/6]
From: Paul Mackerras @ 2008-10-18 12:11 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223532590-8706-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg writes:
> I finally got tired of pressing Alt and some letter to activate menus in Gitk.
> For example in "any" program you can press Alt-F to have the File menu drop
> down and then select the underscored character to select the wanted menu.
>
> This series makes it possible. Friends of TCL may think my solution is too
> hack-ish. It doesn't fix all of the similary problem (mostly button) but
> that is the subject of later patches as it looks like it requires other
> means.
Have a look at what I just pushed out. It adds infrastructure to let
us use "&" in menu items to specify an alt+letter accelerator, but in
a different way to your patches. If you'd like to redo your patch to
add "&" to the menu items, that would be good.
Paul.
^ permalink raw reply
* Re: [Q] submitting patches from gmail
From: Tuncer Ayaz @ 2008-10-18 12:16 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: git
In-Reply-To: <ee2a733e0810180508m466f3ea1i9c63b47177f6e12d@mail.gmail.com>
On Sat, Oct 18, 2008 at 2:08 PM, Leo Razoumov <slonik.az@gmail.com> wrote:
> Hi Everyone,
> I wonder what is the preferred way to submit patches from a gmail account.
> Google mail auto wraps long lines and there is no way to change this setting.
> Safe way would be to use attachments. Are they allowed on git mailing list?
I do use git send-mail with msmtp as the SMTP client and smtp.gmail.com as
the host. If you are able to go that route it would solve your problem.
^ permalink raw reply
* Re: [PATCH 1/3] add alloc_ref_with_prefix()
From: René Scharfe @ 2008-10-18 12:35 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <36ca99e90810180507q2dedf4ck7262239ae91d892f@mail.gmail.com>
Bert Wesarg schrieb:
> On Sat, Oct 18, 2008 at 11:39, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>>> +static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
>>>> + const char *name)
>>>> +{
>>>> + size_t len = strlen(name);
>>>> + struct ref *ref = xcalloc(1, sizeof(struct ref) + prefixlen + len + 1);
>>>> + memcpy(ref->name, prefix, prefixlen);
>>>> + memcpy(ref->name + prefixlen, name, len);
>>> Where does you \0-terminate the string?
>> xcalloc() calls calloc(), which zeroes the memory.
> So, you write the memory range twice, just for the last \0?
Well, one could exclude the name part from zeroing, that's true. It's usually
safer to zero a whole block of memory right at allocation time, lest one
forgets, though. I simply kept it they way it was done before.
That said, here's a patch (4/3):
diff --git a/remote.c b/remote.c
index e530a21..184115d 100644
--- a/remote.c
+++ b/remote.c
@@ -753,9 +753,10 @@ static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
const char *name)
{
size_t len = strlen(name);
- struct ref *ref = xcalloc(1, sizeof(struct ref) + prefixlen + len + 1);
+ struct ref *ref = xmalloc(sizeof(struct ref) + prefixlen + len + 1);
+ memset(ref, sizeof(struct ref));
memcpy(ref->name, prefix, prefixlen);
- memcpy(ref->name + prefixlen, name, len);
+ memcpy(ref->name + prefixlen, name, len + 1);
return ref;
}
^ permalink raw reply related
* Re: [Q] submitting patches from gmail
From: Giuseppe Bilotta @ 2008-10-18 12:50 UTC (permalink / raw)
To: git
In-Reply-To: <ee2a733e0810180508m466f3ea1i9c63b47177f6e12d@mail.gmail.com>
On Saturday 18 October 2008 14:08, Leo Razoumov wrote:
> Hi Everyone,
> I wonder what is the preferred way to submit patches from a gmail account.
> Google mail auto wraps long lines and there is no way to change this setting.
> Safe way would be to use attachments. Are they allowed on git mailing list?
I've been sending patches from gmail for a while without problems. It took me
a while to find a working configruation, but I finally managed to do it using
msmtp. I have
[sendemail]
smtpserver = /usr/bin/msmtp
in my ~/.gitconfig
and the following ~/.msmtprc
======
# Example for a user configuration file
# Set default values for all following accounts.
defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
# My email service
account gmail
host smtp.gmail.com
from yourgmailusername@gmail.com
auth on
user yourgmailusername
password yourgmailpassword
# Set a default account
account default : gmail
=========
And to send patches I just use something like
git send-email --to "git@vger.kernel.org" --cc "whoever" 00*
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [Q] submitting patches from gmail
From: Tuncer Ayaz @ 2008-10-18 13:00 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdcm3d$f3k$1@ger.gmane.org>
On Sat, Oct 18, 2008 at 2:50 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> On Saturday 18 October 2008 14:08, Leo Razoumov wrote:
>
>> Hi Everyone,
>> I wonder what is the preferred way to submit patches from a gmail account.
>> Google mail auto wraps long lines and there is no way to change this setting.
>> Safe way would be to use attachments. Are they allowed on git mailing list?
>
> I've been sending patches from gmail for a while without problems. It took me
> a while to find a working configruation, but I finally managed to do it using
> msmtp. I have
>
> [sendemail]
> smtpserver = /usr/bin/msmtp
>
> in my ~/.gitconfig
>
> and the following ~/.msmtprc
>
> ======
> # Example for a user configuration file
>
> # Set default values for all following accounts.
> defaults
> tls on
> tls_trust_file /etc/ssl/certs/ca-certificates.crt
> logfile ~/.msmtp.log
>
> # My email service
> account gmail
> host smtp.gmail.com
> from yourgmailusername@gmail.com
> auth on
> user yourgmailusername
> password yourgmailpassword
as the password is stored in plaintext I prefer
to leave it out and get asked every time I
use mstmp :-).
> # Set a default account
> account default : gmail
> =========
>
> And to send patches I just use something like
>
> git send-email --to "git@vger.kernel.org" --cc "whoever" 00*
^ permalink raw reply
* Re: Archiving tags/branches?
From: SZEDER Gábor @ 2008-10-18 13:02 UTC (permalink / raw)
To: Johan Herland; +Cc: git, SZEDER Gábor, Pete Harlan
In-Reply-To: <200810181315.49265.johan@herland.net>
On Sat, Oct 18, 2008 at 01:15:49PM +0200, Johan Herland wrote:
> Go have a look in .git/packed-refs. Then have a read through
> git-pack-refs(1).
Oh, indeed, my good old refs are there! Thanks for the info.
Gábor
^ permalink raw reply
* Re: Archiving tags/branches?
From: Johan Herland @ 2008-10-18 13:32 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor, Pete Harlan
In-Reply-To: <20081018130204.GB3749@neumann>
On Saturday 18 October 2008, SZEDER Gábor wrote:
> On Sat, Oct 18, 2008 at 01:15:49PM +0200, Johan Herland wrote:
> > Go have a look in .git/packed-refs. Then have a read through
> > git-pack-refs(1).
>
> Oh, indeed, my good old refs are there! Thanks for the info.
BTW, the best way IMHO to archive old refs is to clone your repo (with all
tags/branches) to a backup disk, and then regularly push (git push --all &&
git push --tags) your new tags/branches to this backup. You are now free to
delete these tags/branches from your work repo (they will not be deleted
from the backup unless you use "git push --mirror"). And if you ever need
to retrieve an old tag/branch, it's just a matter of pulling it from the
backup repo. Nice, clean, flexible, and requires no changes to git.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* git-svn crashing perl
From: Alex Bennee @ 2008-10-18 13:42 UTC (permalink / raw)
To: git
Hi,
Doing a git-sv fetch --fetch-all is generating a SEGV in perl while I
try and update my repo. Although I can look at the backtrace in perl
it doesn't really tell me much. Any tips on how I can get more info?
--
Alex, homepage: http://www.bennee.com/~alex/
^ permalink raw reply
* Re: [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Nanako Shiraishi @ 2008-10-18 13:40 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Junio C Hamano, git
In-Reply-To: <87vdvq5lu4.fsf_-_@cup.kalibalik.dk>
Quoting Anders Melchiorsen <mail@cup.kalibalik.dk>:
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 7788d4f..7604a13 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -137,7 +137,7 @@ endif::git-format-patch[]
> --diff-filter=[ACDMRTUXB*]::
> Select only files that are Added (`A`), Copied (`C`),
> Deleted (`D`), Modified (`M`), Renamed (`R`), have their
> - type (mode) changed (`T`), are Unmerged (`U`), are
> + type (symlink/regular file) changed (`T`), are Unmerged (`U`), are
> Unknown (`X`), or have had their pairing Broken (`B`).
> Any combination of the filter characters may be used.
> When `*` (All-or-none) is added to the combination, all
> --
> 1.6.0.2.514.g23abd3
Are symlinks and regular files the only kind of object you can see in diff? What happens when a file or directory changes to a submodule?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Garry Dolley @ 2008-10-18 13:49 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Richard Hartmann, git
In-Reply-To: <48F7A4F8.2080600@jaeger.mine.nu>
On Thu, Oct 16, 2008 at 10:32:56PM +0200, Christian Jaeger wrote:
> Hm, I don't see a fundamental technical problem which would prevent one
> from implementing the ability to checkout only a subdirectory into the
> working directory (i.e. to add options to Git to make it reflect the
> working directory as being a subdirectory of what is in Git's database). At
> this level I don't see anything inherently different from SVN--except maybe
> for directory renames: if someone else is renaming the directory you've
> checked out, what should happend with your checkout? Git's filebased rename
> tracking would just lead to everything vanishing from your checkout. I
> don't know what happens in SVN, maybe it keeps track of the directory
> rename and still sends you the changes of the directory you've checked out
> even if it has now a different name on the server?
>
> Anyway, an unavoidable difference is that you have to always clone the
> whole Git *database*. With SVN the database stays on the server, with Git
> it is being cloned. Just as I expect SVN to need the whole database to be
> [...]
Right, but I think cloning the entire git database just to get a
subdir is a fundamental technical problem. It's no different than
git-clone + checkout + rm -rf <what I don't want in working tree>
In that sense, git already has support for cloning subdirectories,
which is why I don't think this method applies to what the original
post author meant when they referred to "support for cloning sub
directories".
:)
--
Garry Dolley
ARP Networks, Inc.
http://scie.nti.st
Los Angeles County REACT, Unit 336
WQGK336
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-18 14:01 UTC (permalink / raw)
To: Garry Dolley; +Cc: Richard Hartmann, git
In-Reply-To: <20081018134906.GA13894@garry-thinkpad.arpnetworks.com>
Garry Dolley wrote:
> On Thu, Oct 16, 2008 at 10:32:56PM +0200, Christian Jaeger wrote:
>
>> Hm, I don't see a fundamental technical problem which would prevent one
>> from implementing the ability to checkout only a subdirectory into the
>> working directory (i.e. to add options to Git to make it reflect the
>> working directory as being a subdirectory of what is in Git's database). At
>> this level I don't see anything inherently different from SVN--except maybe
>> for directory renames: if someone else is renaming the directory you've
>> checked out, what should happend with your checkout? Git's filebased rename
>> tracking would just lead to everything vanishing from your checkout. I
>> don't know what happens in SVN, maybe it keeps track of the directory
>> rename and still sends you the changes of the directory you've checked out
>> even if it has now a different name on the server?
>>
>> Anyway, an unavoidable difference is that you have to always clone the
>> whole Git *database*. With SVN the database stays on the server, with Git
>> it is being cloned. Just as I expect SVN to need the whole database to be
>> [...]
>>
>
> Right, but I think cloning the entire git database just to get a
> subdir is a fundamental technical problem. It's no different than
> git-clone + checkout + rm -rf <what I don't want in working tree>
>
We're in "violent agreement" here.
> In that sense, git already has support for cloning subdirectories,
> which is why I don't think this method applies to what the original
> post author meant when they referred to "support for cloning sub
> directories".
>
I just think it's worth pointing out the difference between the working
dir and the database. It should be as easy to implement checking out
subdirectories in Git as it was in SVN (except, again, that, iff
directory renames should be tracked, some code would have to be written
to find out about directory renames, which SVN solves in a simpler way
by just requiring that the user specifies renames explicitely). It's
worth pointing out that working directory checkouts and database cloning
are separate operatoins and it's only the database cloning which is, per
definition (as it is a distributed VCS) different from SVN.
> :)
>
If you really wanted, I suppose you could additionally look into
implementing a kind of shallow cloning that only copies objects over the
wire which are necessary for representing the subdirectory you're
interested in.
Christian.
^ permalink raw reply
* Re: [Q] submitting patches from gmail
From: Leo Razoumov @ 2008-10-18 14:12 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdcm3d$f3k$1@ger.gmane.org>
Giuseppe,
Thanks for the help!
BTW, what is /etc/ssl/certs/ca-certificates.crt and how to generate it?
--Leo--
On 10/18/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> On Saturday 18 October 2008 14:08, Leo Razoumov wrote:
>
> > Hi Everyone,
> > I wonder what is the preferred way to submit patches from a gmail account.
> > Google mail auto wraps long lines and there is no way to change this setting.
> > Safe way would be to use attachments. Are they allowed on git mailing list?
>
>
> I've been sending patches from gmail for a while without problems. It took me
> a while to find a working configruation, but I finally managed to do it using
> msmtp. I have
>
> [sendemail]
> smtpserver = /usr/bin/msmtp
>
> in my ~/.gitconfig
>
> and the following ~/.msmtprc
>
> ======
> # Example for a user configuration file
>
> # Set default values for all following accounts.
> defaults
> tls on
> tls_trust_file /etc/ssl/certs/ca-certificates.crt
> logfile ~/.msmtp.log
>
> # My email service
> account gmail
> host smtp.gmail.com
> from yourgmailusername@gmail.com
> auth on
> user yourgmailusername
> password yourgmailpassword
>
> # Set a default account
> account default : gmail
> =========
>
> And to send patches I just use something like
>
> git send-email --to "git@vger.kernel.org" --cc "whoever" 00*
>
> --
> Giuseppe "Oblomov" Bilotta
>
>
> --
> 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
>
^ permalink raw reply
* Re: [Q] submitting patches from gmail
From: Felipe Contreras @ 2008-10-18 14:20 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Giuseppe Bilotta, git
In-Reply-To: <ee2a733e0810180712k42a4dbb6m3d4e9de717a79b53@mail.gmail.com>
On Sat, Oct 18, 2008 at 5:12 PM, Leo Razoumov <slonik.az@gmail.com> wrote:
> Giuseppe,
> Thanks for the help!
>
> BTW, what is /etc/ssl/certs/ca-certificates.crt and how to generate it?
Your distro should provide that along with openssl.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] feature request: git-mergetool --force
From: Jeff King @ 2008-10-18 15:48 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <48F91E59.50202@gmail.com>
On Sat, Oct 18, 2008 at 12:23:05AM +0100, William Pursell wrote:
> I occasionally use commands like 'cp $REMOTE $MERGED' with
> mergetool, and would prefer to not be prompted to start
> the tool on each file. A --force option would be handy.
I think it is reasonable to want to skip this prompt, but I am not sure
"--force" is the right name for such an option. Usually we reserve
--force for "the tool is trying to prevent something destructive or
unusual, and the user wants to override it".
Something like --no-prompt makes more sense to me, though probably
something a little easier to type would be nice (or maybe alias "-n").
-Peff
^ permalink raw reply
* Re: [PATCH v2] parse-opt: migrate builtin-checkout-index.
From: Pierre Habouzit @ 2008-10-18 15:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7v63nqg4f4.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]
On Fri, Oct 17, 2008 at 11:58:23PM +0000, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > +static int option_parse_z(const struct option *opt,
> > + const char *arg, int unset)
> > +{
> > + line_termination = unset;
> > + return 0;
> > +}
> > ...
> > + { OPTION_CALLBACK, 'z', NULL, NULL, NULL,
> > + "paths are separated with NUL character",
> > + PARSE_OPT_NOARG, option_parse_z },
>
> This adds a new feature to say --no-z from the command line, doesn't it?
> And I suspect the feature is broken ;-).
No it doesn't, --no-foo is only active for long options.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Excluding files from git-diff
From: Jeff King @ 2008-10-18 15:59 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Michael J Gruber, Erik Hahn, git
In-Reply-To: <48F8BDA7.50901@pflanze.mine.nu>
On Fri, Oct 17, 2008 at 06:30:31PM +0200, Christian Jaeger wrote:
> For me, adding entries to that file does not make "git diff" or "gitk" or
> even "git ls-files" ignore files matching the entries. Only "git ls-files
> --others --exclude-from=.git/info/exclude" will exclude them. And "git
> diff " and gitk don't seem to know the --exclude-from option.
What you are seeing is:
- ls-files is plumbing, and does not do any exclusion by default. So
you need to use the --exclude-from option, or more easily,
--exclude-standard (which pulls in .git/info/excludes, .gitignore,
and user-level excludes).
- porcelain _does_ do exclusion. However, exclusion does not mean "if
this file is tracked by git, don't include it in the diff." It
merely means "if this file is untracked, pretend like it is not
there." So a diff displayed by "git diff" isn't affected by
exclusions anyway.
> Is there a way to really invert the patterns given to "git diff" or
> alike? I.e. instead of saying "git diff -- * .somedotfile
> .someothernongitignoredotfile" one could just say something like "git
> diff --invert-matches -- .gitignore"? And even better, could one
> configure some such so that it has effect on all tools by default?
No, I don't think there is a way to do that currently. I would probably
generate the file list with a shell snippet:
git diff -- `git ls-files | grep -v .gitignore`
but obviously that is a lot more typing if this is something you are
doing frequently.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox