* 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
* 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: 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
* 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: [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: [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: [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: 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: [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
* [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: [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
* [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: 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
* 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: [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: [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: 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: 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
* [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Anders Melchiorsen @ 2008-10-18 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzll2epuh.fsf@gitster.siamese.dyndns.org>
With the previous text, one could get the understanding that
diff-filter=T also tested for changes in the executable bit.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Junio C Hamano <gitster@pobox.com> writes:
> There are other "commit pickers" such as -S<strting> and
> --diff-filter that do not absolutely have to exist (iow, they could
> also be scripted), but what they pick earned easy shortcuts because
> the need is very common. Once you can demonstrate that the need to
> pick executable-bit changes is also very common, _and_ if you can
> come up with a clean solution, we might add a commit picker that
> looks for changes in executable-ness in the future. I dunno.
You are right that this should be a rare need.
I didn't mean to push for this feature. I just offered to implement
it, as I needed it myself and din't see other ways. A script will work
fine for me, I should have thought of that.
The documentation patch that I promised is here.
Thanks,
Anders.
Documentation/diff-options.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
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
^ permalink raw reply related
* Re: StGIT 0.14.3: extra space is added before e-mail on export after "stg edit"
From: Catalin Marinas @ 2008-10-18 8:48 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: git
In-Reply-To: <200810152025.19995.arvidjaar@mail.ru>
2008/10/15 Andrey Borzenkov <arvidjaar@mail.ru>:
> Funny problem. I have following export template:
>
> Subject: [PATCH] %(shortdescr)s
> From: %(authname)s %(authemail)s
>
> %(longdescr)s
> Signed-off-by: %(authname)s %(authemail)s
The default templates contain "%(authname)s <%(authemail)s>", i.e.
with the angle brackets arount authemail and I've never seen this
problem. Does it work if you change them (or use the default
templates)?
--
Catalin
^ permalink raw reply
* [PATCH 3/3] make alloc_ref_from_str() the new alloc_ref()
From: René Scharfe @ 2008-10-18 8:44 UTC (permalink / raw)
Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <48F9A13D.3090401@lsrfire.ath.cx>
With all calls to alloc_ref() gone, we can remove it and then we're free
to give alloc_ref_from_str() the shorter name. It's a much nicer
interface, as the callers always need to have a name string when they
allocate a ref anyway and don't need to calculate and pass its length+1
any more.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-fetch.c | 4 ++--
connect.c | 2 +-
http-push.c | 4 ++--
remote.c | 21 +++++++--------------
remote.h | 4 +---
transport.c | 8 ++++----
walker.c | 2 +-
7 files changed, 18 insertions(+), 27 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..e008ee9 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -521,8 +521,8 @@ static void find_non_local_tags(struct transport *transport,
will_fetch(head, ref->old_sha1))) {
string_list_insert(ref_name, &new_refs);
- rm = alloc_ref_from_str(ref_name);
- rm->peer_ref = alloc_ref_from_str(ref_name);
+ rm = alloc_ref(ref_name);
+ rm->peer_ref = alloc_ref(ref_name);
hashcpy(rm->old_sha1, ref_sha1);
**tail = rm;
diff --git a/connect.c b/connect.c
index b69060b..0c50d0a 100644
--- a/connect.c
+++ b/connect.c
@@ -90,7 +90,7 @@ struct ref **get_remote_heads(int in, struct ref **list,
continue;
if (nr_match && !path_match(name, nr_match, match))
continue;
- ref = alloc_ref_from_str(buffer + 41);
+ ref = alloc_ref(buffer + 41);
hashcpy(ref->old_sha1, old_sha1);
*list = ref;
list = &ref->next;
diff --git a/http-push.c b/http-push.c
index 42f4d78..5cecef4 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1780,7 +1780,7 @@ static void one_remote_ref(char *refname)
struct ref *ref;
struct object *obj;
- ref = alloc_ref_from_str(refname);
+ ref = alloc_ref(refname);
if (http_fetch_ref(remote->url, ref) != 0) {
fprintf(stderr,
@@ -1887,7 +1887,7 @@ static void add_remote_info_ref(struct remote_ls_ctx *ls)
char *ref_info;
struct ref *ref;
- ref = alloc_ref_from_str(ls->dentry_name);
+ ref = alloc_ref(ls->dentry_name);
if (http_fetch_ref(remote->url, ref) != 0) {
fprintf(stderr,
diff --git a/remote.c b/remote.c
index 44d681d..e530a21 100644
--- a/remote.c
+++ b/remote.c
@@ -759,15 +759,9 @@ static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
return ref;
}
-struct ref *alloc_ref(unsigned namelen)
+struct ref *alloc_ref(const char *name)
{
- struct ref *ret = xcalloc(1, sizeof(struct ref) + namelen);
- return ret;
-}
-
-struct ref *alloc_ref_from_str(const char* str)
-{
- return alloc_ref_with_prefix("", 0, str);
+ return alloc_ref_with_prefix("", 0, name);
}
static struct ref *copy_ref(const struct ref *ref)
@@ -878,20 +872,20 @@ static struct ref *try_explicit_object_name(const char *name)
struct ref *ref;
if (!*name) {
- ref = alloc_ref_from_str("(delete)");
+ ref = alloc_ref("(delete)");
hashclr(ref->new_sha1);
return ref;
}
if (get_sha1(name, sha1))
return NULL;
- ref = alloc_ref_from_str(name);
+ ref = alloc_ref(name);
hashcpy(ref->new_sha1, sha1);
return ref;
}
static struct ref *make_linked_ref(const char *name, struct ref ***tail)
{
- struct ref *ret = alloc_ref_from_str(name);
+ struct ref *ret = alloc_ref(name);
tail_link_ref(ret, tail);
return ret;
}
@@ -1196,9 +1190,8 @@ static struct ref *get_local_ref(const char *name)
if (!name)
return NULL;
- if (!prefixcmp(name, "refs/")) {
- return alloc_ref_from_str(name);
- }
+ if (!prefixcmp(name, "refs/"))
+ return alloc_ref(name);
if (!prefixcmp(name, "heads/") ||
!prefixcmp(name, "tags/") ||
diff --git a/remote.h b/remote.h
index c6163ff..d2e170c 100644
--- a/remote.h
+++ b/remote.h
@@ -55,9 +55,7 @@ struct refspec {
extern const struct refspec *tag_refspec;
-struct ref *alloc_ref(unsigned namelen);
-
-struct ref *alloc_ref_from_str(const char* str);
+struct ref *alloc_ref(const char *name);
struct ref *copy_ref_list(const struct ref *ref);
diff --git a/transport.c b/transport.c
index 3d03475..cfb7350 100644
--- a/transport.c
+++ b/transport.c
@@ -75,7 +75,7 @@ static int read_loose_refs(struct strbuf *path, int name_offset,
if (fd < 0)
continue;
- next = alloc_ref_from_str(path->buf + name_offset);
+ next = alloc_ref(path->buf + name_offset);
if (read_in_full(fd, buffer, 40) != 40 ||
get_sha1_hex(buffer, next->old_sha1)) {
close(fd);
@@ -126,7 +126,7 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
(*list)->next->name)) > 0)
list = &(*list)->next;
if (!(*list)->next || cmp < 0) {
- struct ref *next = alloc_ref_from_str(buffer + 41);
+ struct ref *next = alloc_ref(buffer + 41);
buffer[40] = '\0';
if (get_sha1_hex(buffer, next->old_sha1)) {
warning ("invalid SHA-1: %s", buffer);
@@ -499,7 +499,7 @@ static struct ref *get_refs_via_curl(struct transport *transport)
strbuf_release(&buffer);
- ref = alloc_ref_from_str("HEAD");
+ ref = alloc_ref("HEAD");
if (!walker->fetch_ref(walker, ref) &&
!resolve_remote_symref(ref, refs)) {
ref->next = refs;
@@ -540,7 +540,7 @@ static struct ref *get_refs_from_bundle(struct transport *transport)
die ("Could not read bundle '%s'.", transport->url);
for (i = 0; i < data->header.references.nr; i++) {
struct ref_list_entry *e = data->header.references.list + i;
- struct ref *ref = alloc_ref_from_str(e->name);
+ struct ref *ref = alloc_ref(e->name);
hashcpy(ref->old_sha1, e->sha1);
ref->next = result;
result = ref;
diff --git a/walker.c b/walker.c
index 6b4cf70..679adab 100644
--- a/walker.c
+++ b/walker.c
@@ -191,7 +191,7 @@ static int interpret_target(struct walker *walker, char *target, unsigned char *
if (!get_sha1_hex(target, sha1))
return 0;
if (!check_ref_format(target)) {
- struct ref *ref = alloc_ref_from_str(target);
+ struct ref *ref = alloc_ref(target);
if (!walker->fetch_ref(walker, ref)) {
hashcpy(sha1, ref->old_sha1);
free(ref);
--
1.6.0.2.542.gde55
^ permalink raw reply related
* [PATCH 2/3] use alloc_ref_from_str() everywhere
From: René Scharfe @ 2008-10-18 8:41 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <48F9A054.4010703@lsrfire.ath.cx>
Replace pairs of alloc_ref() and strcpy() with alloc_ref_from_str(),
simplifying the code.
In connect.c, also a pair of alloc_ref() and memcpy() is replaced --
the additional cost of a strlen() call should not have too much of an
impact. Consistency and simplicity are more important.
In remote.c, the code was allocating 11 bytes more than needed for
the name part, but I couldn't see them being used for anything.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
connect.c | 3 +--
remote.c | 3 +--
transport.c | 6 ++----
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/connect.c b/connect.c
index 67d2cd8..b69060b 100644
--- a/connect.c
+++ b/connect.c
@@ -90,9 +90,8 @@ struct ref **get_remote_heads(int in, struct ref **list,
continue;
if (nr_match && !path_match(name, nr_match, match))
continue;
- ref = alloc_ref(name_len + 1);
+ ref = alloc_ref_from_str(buffer + 41);
hashcpy(ref->old_sha1, old_sha1);
- memcpy(ref->name, buffer + 41, name_len + 1);
*list = ref;
list = &ref->next;
}
diff --git a/remote.c b/remote.c
index 98cbcf9..44d681d 100644
--- a/remote.c
+++ b/remote.c
@@ -878,8 +878,7 @@ static struct ref *try_explicit_object_name(const char *name)
struct ref *ref;
if (!*name) {
- ref = alloc_ref(20);
- strcpy(ref->name, "(delete)");
+ ref = alloc_ref_from_str("(delete)");
hashclr(ref->new_sha1);
return ref;
}
diff --git a/transport.c b/transport.c
index 5110c56..3d03475 100644
--- a/transport.c
+++ b/transport.c
@@ -75,15 +75,14 @@ static int read_loose_refs(struct strbuf *path, int name_offset,
if (fd < 0)
continue;
- next = alloc_ref(path->len - name_offset + 1);
+ next = alloc_ref_from_str(path->buf + name_offset);
if (read_in_full(fd, buffer, 40) != 40 ||
get_sha1_hex(buffer, next->old_sha1)) {
close(fd);
free(next);
continue;
}
close(fd);
- strcpy(next->name, path->buf + name_offset);
(*tail)->next = next;
*tail = next;
}
@@ -127,14 +126,13 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
(*list)->next->name)) > 0)
list = &(*list)->next;
if (!(*list)->next || cmp < 0) {
- struct ref *next = alloc_ref(len - 40);
+ struct ref *next = alloc_ref_from_str(buffer + 41);
buffer[40] = '\0';
if (get_sha1_hex(buffer, next->old_sha1)) {
warning ("invalid SHA-1: %s", buffer);
free(next);
continue;
}
- strcpy(next->name, buffer + 41);
next->next = (*list)->next;
(*list)->next = next;
list = &(*list)->next;
--
1.6.0.2.542.gde55
^ permalink raw reply related
* [PATCH 1/3] add alloc_ref_with_prefix()
From: René Scharfe @ 2008-10-18 8:37 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
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);
+ return ref;
+}
+
struct ref *alloc_ref(unsigned namelen)
{
struct ref *ret = xcalloc(1, sizeof(struct ref) + namelen);
@@ -757,9 +767,7 @@ struct ref *alloc_ref(unsigned namelen)
struct ref *alloc_ref_from_str(const char* str)
{
- struct ref *ret = alloc_ref(strlen(str) + 1);
- strcpy(ret->name, str);
- return ret;
+ return alloc_ref_with_prefix("", 0, str);
}
static struct ref *copy_ref(const struct ref *ref)
@@ -1152,10 +1160,8 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
struct ref *cpy = copy_ref(ref);
match = ref->name + remote_prefix_len;
- cpy->peer_ref = alloc_ref(local_prefix_len +
- strlen(match) + 1);
- sprintf(cpy->peer_ref->name, "%s%s",
- refspec->dst, match);
+ cpy->peer_ref = alloc_ref_with_prefix(refspec->dst,
+ local_prefix_len, match);
if (refspec->force)
cpy->peer_ref->force = 1;
*tail = cpy;
@@ -1188,7 +1194,6 @@ struct ref *get_remote_ref(const struct ref *remote_refs, const char *name)
static struct ref *get_local_ref(const char *name)
{
- struct ref *ret;
if (!name)
return NULL;
@@ -1198,15 +1203,10 @@ static struct ref *get_local_ref(const char *name)
if (!prefixcmp(name, "heads/") ||
!prefixcmp(name, "tags/") ||
- !prefixcmp(name, "remotes/")) {
- ret = alloc_ref(strlen(name) + 6);
- sprintf(ret->name, "refs/%s", name);
- return ret;
- }
+ !prefixcmp(name, "remotes/"))
+ return alloc_ref_with_prefix("refs/", 5, name);
- ret = alloc_ref(strlen(name) + 12);
- sprintf(ret->name, "refs/heads/%s", name);
- return ret;
+ return alloc_ref_with_prefix("refs/heads/", 11, name);
}
int get_fetch_map(const struct ref *remote_refs,
--
1.6.0.2.542.gde55
^ permalink raw reply related
* Re: [PATCH 1/3] for-each-ref: utilize core.warnambiguousrefs for strict refname:short format
From: Bert Wesarg @ 2008-10-18 6:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, szeder
In-Reply-To: <20081018015010.GA14786@spearce.org>
On Sat, Oct 18, 2008 at 03:50, Shawn O. Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Shawn, was there any issue with this one? The patch changes the function
>> signature for no good reason (at least, it does not have anything to do
>> with the stated purpose of the change), but other than that, I think what
>> it attempts to do makes sense.
>
> No, aside from the signature issue I think its reasonable.
Ok, I will post a new single patch, that does only this.
Bert
>
> --
> Shawn.
>
^ permalink raw reply
* Re: externals program, way to do svn:externals-like subproject management without git-submodule
From: Miles Georgi @ 2008-10-18 6:48 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git List
In-Reply-To: <853238710809250037q448046cekc901e5f48acd14a3@mail.gmail.com>
Avery, and to whoever else might be interested in this app:
I have added a freeze feature to ext
It works like this:
ext freeze project_name [revision]
This records the revision in the .externals file under that
subproject's entry. When it is checked out/exported it fetches that
revision.
If you leave the revision off of the command, it uses the revision the
project is currently checked out at.
Also, I got a request to add a cross repository tagging feature, so
that you can create a tag at the top level that remembers
the revisions of all the subprojects at that time. I thought this was
pretty interesting, and could just implement it as a hash
of project to revision numbers/sha1s in a seperate file, perhaps
called .exttags Doesn't seem like it would be hard to implement
now that subprojects can be checked out at specific revisions.
Miles
On Thu, Sep 25, 2008 at 12:37 AM, Miles Georgi <azimux@gmail.com> wrote:
> Avery, and anybody else who might be interested:
>
> I have released a new version of externals which uses the format
> recommended by Avery.
>
> That should make it easier to add new features, such as the ones
> mentioned in Avery's email. I've switched some of my projects to it
> and it seems to be working fine.
> I've bumped the version to 0.1.0 to signify a more betaish stage :)
>
> Miles
>
> On Sat, Sep 13, 2008 at 9:21 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>> On Sat, Sep 13, 2008 at 9:06 PM, Miles Georgi <azimux@gmail.com> wrote:
>>> I'll just answer by numbers, I hope it's not too inconvenient to have
>>> to scroll between emails to see which point I'm talking about :/
>>
>> In general, it's better to use inline quoting. It's okay if the
>> quotes get long, because long messages are manageable, but messages
>> that require you to look at *other* messages at the same time are just
>> a PITA. Luckily, however, I at least remember what we're talking
>> about :)
>>
>>> 1. Oh, I'm not really aware of what "cvs export" does. I assumed it
>>> meant something very similar to "svn export" Running "ext export URL"
>>> on a project manage by subversion with all the subprojects managed by
>>> subversion simply runs "svn export URL" followed by an "svn export"
>>> for each subproject, hence the name. Calling it "shallow" makes sense
>>> for git since I'm using --depth 1, but since "svn export" doesn't
>>> create the .svn directories necessary to make it a working directory,
>>> I don't really know if I would call that shallow. For git's
>>> implementation of export, I was thinking of just doing a clone and
>>> then deleting .git/ which also wouldn't be shallow.
>>
>> Aha, sorry. In that case, it does do exactly what cvs export and svn
>> export do, so I take it back. I would never use it (because I always
>> deploy my .git directories along with the app itself... free
>> backups!). But the name is correct.
>>
>>> 3. I am also bothered by the inconsistency of the meaning of [main]
>>> and [git/svn] along with everything you pointed out.
>>>
>>> Question? Is it okay to have "/" characters in the ini section name?
>>
>> Yes. In general, a section name can have anything except a ] in it,
>> and a key can have anything but an = in it. (Well, obviously we
>> should expect that there are no CR, LF, or NUL characters either.)
>>
>> If you want to do it exactly like git, you would name your sections like
>>
>> [ext "libs/my/plugin"]
>>
>> instead of my earlier suggestion of
>>
>> [libs/my/plugin]
>>
>> This would be compatible with git-config. Also, this method means
>> that the [main] section could never be confused with a particular ext
>> section.
>>
>>> I wonder if it would be okay to just put the repository
>>> as the section name. That way scm and path could be excluded for
>>> situations where the defaults are sufficient. Although I guess this
>>> would have the implication of changing a projects repository
>>> (something that happens way more frequently than changing the path
>>> it's installed to) some what messy since it's being identified by its
>>> repository.
>>
>> I think you answered your own question there :) Personally, it feels
>> natural to me to index a submodule by its local path, and have the URL
>> be an attribute of that submodule, rather than the other way around.
>> This makes sense since every local path can only have one submodule on
>> it, while in insane situations, you can imagine having exactly the
>> same repo (perhaps different revisions or branches?) cloned into two
>> different locations.
>>
>>> But yeah, if this feature makes somebody nervous, they can just always
>>> explicitly give the path (which they'll have to do if it's not a rails
>>> app.) It also detects that it's a rails app so it will complain if
>>> you leave the path off in a non-rails app. It won't try to put
>>> something in vendor/plugins of a non-rails app just because a path is
>>> missing.
>>
>> Okay, if it's not in rails mode, I guess it won't cause problems... as
>> long as the rails auto-detection is extremely reliable and can be
>> turned off somehow.
>>
>>> 5. Yeah that's a good idea. I could create a command that adds an
>>> existing subproject to the .externals and updates the ignore properly.
>>> To get this effect at the moment, one would manually add the
>>> subproject to .externals and run "ext update_ignore" I personally
>>> don't usually find myself doing this though. I almost always want the
>>> subproject to be added to the project. I need to make an "ext
>>> uninstall" for backing out if you don't like it. I personally would
>>> rather manually remove the item from .externals than have to issue two
>>> commands to install it. But your idea of a save command is very
>>> powerful, especially with the branch switching ideas you have in #8
>>> below.
>>
>> Right, it wouldn't matter which way you did it, but the other options
>> below fit really nicely into a 'git save' operation.
>>
>> Also, I personally think it's more elegant to not have to do "undo"
>> operations as a normal part of your workflow. Checkout work work work
>> save seems nicer to me than Checkout uninstall work work work.
>>
>> [nested submodules]
>>> 6. Hey that's a pretty interesting idea! I hadn't even thought about
>>> that as I have not yet personally encountered that use case. I've
>>> been hoping that rails plugins could have their own vendor/plugins
>>> directory because if they did I would also use something like that all
>>> the time. This is definitely something that should be implemented at
>>> some point.
>>
>> Well, like I said, I'm doing it right now in one of my projects :)
>> But it doesn't have to be a high priority.
>>
>>> 7. Agreed (for the most part.) I almost never want to do this for my
>>> own projects as I almost always want the branch tip no matter what.
>>> I'd rather run tests and discover that something has broke before
>>> deploying than have to go to all my projects and advance the commit
>>> manually.
>>
>> Ouch, I would never want to do it that way! If my app has been
>> deployed for three months and someone reports a minor bug, I just want
>> to fix that one bug and redeploy safely and immediately. I certainly
>> don't want to risk breaking everything by upgrading a bunch of
>> unrelated modules.
>>
>>> the way I
>>> currently have been handling this is by having my own rails repository
>>> at git://github.com/azimux/rails.git that I occaisionally will merge
>>> rails/rails.git with and run tests for my larger applications. If I
>>> like how it behaves I push the merged tip back out to azimux/rails.git
>>> which is what all my projects reference in their .externals file.
>>
>> This sounds like a convoluted way of just doing what I suggested. :)
>>
>> Oh, that reminds me of another feature that would be awesome:
>> *alternate* repository URLs. In your example above, let's say you've
>> made some rails customizations, anyone cloning your project will have
>> to get your version. But one day, the rails developers merge in your
>> changes, so now their primary repo (probably with more bandwidth,
>> uptime, etc) will work again. If the ext lists *all* the repositories
>> you might need, ext can just git fetch from all of them, then checkout
>> the commit in question, and it will always work.
>>
>>> And I would definitely not
>>> have it disconnected from a branch if it can be avoided. I guess it
>>> would checkout a specific commit but be on a branch, and then if the
>>> developer needed to edit the subproject, they would realize it was
>>> non-fastforward when they pushed and then do a rebase against the
>>> current tip? I'm not 100% sure how this workflow would normally occur
>>> as I've not yet had to rebase anything, and when I was using
>>> git-submodule, I would always checkout a branch tip if I had to edit
>>> the subproject and then would do a git add submodule/path to point at
>>> the new commit when I was done.
>>
>> It can be simpler than that. Essentially, what you do is:
>>
>> git fetch origin
>> git checkout COMMITID
>> git branch -D BRANCHNAME
>> git checkout -b BRANCHNAME
>>
>> The first checkout puts you on a disconnected HEAD temporarily, just
>> in case you were previously on a branch called BRANCHNAME, which would
>> have prevented the "delete branch" operation from working. Then we
>> delete the branch, and recreate it at the new location (COMMITID).
>>
>> With that in place, git will know how to do everything else
>> automatically, but it's up to the user. You can pull/merge the latest
>> changes from another branch, or rebase, etc.
>>
>> Note that as a safety measure, you probably want to refuse to actually
>> do the above if either of:
>> a) The git filesystem or index shows uncommitted files
>> b) The current git commit != the commit ext thinks is checked out right now.
>>
>>> 9. I wasn't planning on having any sort of commit/push-type features
>>> since the workflows of the SCMs are different when it comes to
>>> commiting/pushing. For example, if it's a subversion project it needs
>>> to do an "svn commit" requiring a log message. And sometimes I really
>>> only want to push a subset of the subprojects that I've modified.
>>
>> I think it would be really cool if ext could just figure this out.
>> For example, it's easy to tell that in svn, your changes have to be
>> committed (ie. no dirty tree) and in git, the upstream repo needs to
>> contain your commitid (it's been pushed).
>>
>> If you only want to push a subset of projects, that's fine, but you
>> can do it in the individual subdirs by hand anyhow. On the other
>> hand, I'd say you *don't* want to ever push the parent repo without
>> first pushing all your changes, particularly if you have the commitid
>> encoded in the .externals file, or you'll produce an un-checkout-able
>> repository.
>>
>>> Maybe what I could do is have "ext status" also see if a subproject
>>> could be pushed and issue a warning like "<subproject> has commits
>>> that are missing from <remote name>. Did you forget to push?" This
>>> would be unnecessary for subversion managed subprojects as if it's up
>>> to date, then it's pushed and vice versa, but for git it would be very
>>> helpful for when the status is empty due to commits being performed,
>>> but is not yet pushed out to it's origin.
>>
>> Yes, that would be almost as good.
>>
>>> I don't know if I would
>>> like it automatically doing the pushing though, but it could be
>>> doable, maybe with a command with the name "git" in it to specify it's
>>> scm specific, like "ext gitpush" or I could just have an "ext push"
>>> that does nothing for svn/cvs projects.
>>
>> I don't think it should do nothing for svn/cvs projects: it should
>> either help you commit, or abort with a helpful message if your repo
>> is dirty, or something like that.
>>
>> Hope this helps.
>>
>> Have fun,
>>
>> Avery
>>
>
^ 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