* Re: clone fails: Could not get the current working directory
From: Alex Riesen @ 2008-09-23 14:12 UTC (permalink / raw)
To: John Freeman; +Cc: git
In-Reply-To: <48D8EDDA.3050804@cs.tamu.edu>
2008/9/23 John Freeman <jfreeman@cs.tamu.edu>:
> Alex Riesen wrote:
>>
>> Do these work:
>> $ ssh john@remote.system.edu ls -R /home/bob/path/to/repo
>> $ ssh john@remote.system.edu 'cd /home/bob/path/to/repo && pwd'
>>
>
> Yes, they do. I wish the mailing list did better threading; please see my
> other posts if you happened to miss them:
>
> http://article.gmane.org/gmane.comp.version-control.git/96442
> http://article.gmane.org/gmane.comp.version-control.git/96505
>
Saw them. .bashrc (/etc/bashrc too) is not used for non-interactive sessions,
like yours (of course, you can source them from
.profile/.bash_login/.bash_profile).
Have you tried the commands exactly? (Even more interesting would be to try
a simple getpwd program which prints errno)
^ permalink raw reply
* Re: Locking binary files
From: Mario Pareja @ 2008-09-23 14:14 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: git
In-Reply-To: <48D8CFF1.8030403@panasas.com>
> It should be easy for a company to set a policy where a couple of scripts
> must be run for particular type of files. Given that, the implementation
> of such scripts is easy:
>
> For every foo.bin there is possibly a foo.bin.lock file.
>
> Lock-script look for absence of the lock-file at upstream then git-add
> the file (With some info that tells users things like who has the file).
> If git-push fails, since I'm adding a file and someone already added
> it while I was pushing, then the lock is not granted.
>
> Unlock-script will git-rm the lock-file and push.
>
> In both scripts mod-bits of original file can be toggled for
> read-only/write signaling to the user. (At upstream the file is always
> read-only)
>
> This can also work in a distributed system with more then one tier of
> servers. (Locks pushed to the most upstream server)
>
> Combine that with git's mail notifications for commits and you have a
> system far more robust then svn will ever want to be
>
> My $0.017
> Boaz
>
This is a reasonable approach to obtaining the desired functionality.
Unfortunately, I have not seen any third-party packages implementing
such a feature. It seems to me the problem is general enough to be
solved once rather than requiring organizations wishing to use git to
implement an in-house locking system. It simply creates more friction.
Perhaps, when I have the time, I will come up with something others
can use. For now, unfortunately, it seems I am out of luck?
Mario
^ permalink raw reply
* Re: Locking binary files
From: Alex Riesen @ 2008-09-23 14:28 UTC (permalink / raw)
To: Mario Pareja; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <94c1db200809230656q4a9a765dw2354c0058b1d940c@mail.gmail.com>
2008/9/23 Mario Pareja <mpareja.dev@gmail.com>:
>> So it's a communication issue then.
>
> Yes, but I think the communication of this information needs to happen
> as part of a developers normal work-flow rather than requiring them to
> remember to check an external system.
Look at pre-receive and update hooks. They can deny a push operation and
get enough information to notice a change to the path of your unlucky file.
And yes, *you* have to do that yourself.
^ permalink raw reply
* Re: Locking binary files
From: Boaz Harrosh @ 2008-09-23 14:35 UTC (permalink / raw)
To: Mario Pareja; +Cc: git
In-Reply-To: <94c1db200809230714k6b007919yfd8ad1b86cbcd385@mail.gmail.com>
Mario Pareja wrote:
>> It should be easy for a company to set a policy where a couple of scripts
>> must be run for particular type of files. Given that, the implementation
>> of such scripts is easy:
>>
>> For every foo.bin there is possibly a foo.bin.lock file.
>>
>> Lock-script look for absence of the lock-file at upstream then git-add
>> the file (With some info that tells users things like who has the file).
>> If git-push fails, since I'm adding a file and someone already added
>> it while I was pushing, then the lock is not granted.
>>
>> Unlock-script will git-rm the lock-file and push.
>>
>> In both scripts mod-bits of original file can be toggled for
>> read-only/write signaling to the user. (At upstream the file is always
>> read-only)
>>
>> This can also work in a distributed system with more then one tier of
>> servers. (Locks pushed to the most upstream server)
>>
>> Combine that with git's mail notifications for commits and you have a
>> system far more robust then svn will ever want to be
>>
>> My $0.017
>> Boaz
>>
>
> This is a reasonable approach to obtaining the desired functionality.
> Unfortunately, I have not seen any third-party packages implementing
> such a feature. It seems to me the problem is general enough to be
> solved once rather than requiring organizations wishing to use git to
> implement an in-house locking system. It simply creates more friction.
> Perhaps, when I have the time, I will come up with something others
> can use. For now, unfortunately, it seems I am out of luck?
>
> Mario
> --
The open-source my friend. First comes first implements. More and more
development platforms use XML files in where they used a binary file
format before. Just for these cases. Git is mostly used with open-source
and/or very new systems that don't have binary file formats. OK graphics is
another thing, I guess.
So you are welcome to it. "git-lock" is available
Boaz
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Alex Riesen @ 2008-09-23 14:37 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Johannes Sixt, Junio C Hamano, Steffen Prohaska
In-Reply-To: <20080923140144.GN21650@dpotapov.dyndns.org>
2008/9/23 Dmitry Potapov <dpotapov@gmail.com>:
> This patch introduces the GIT_FAST_STAT environment variable. If this
> variable is not set then Git will work as before. However, if it is set
> then the Cygwin version of Git will try to use a Win32 API function if
> it is possible to speed up stat/lstat.
>
> This fast mode works only for relative paths. It is assumed that the
> whole repository is located inside one directory without using Cygwin
> mount to bind external paths inside of the current tree.
Why runtime conditional? Why conditional at all? Why not fallback
to cygwin's slow stat on absolute pathnames like you do for symlinks?
> +/*
> + * This are startup stubs, which choose what implementation of lstat/stat
why do you need two of them? Isn't one not enough?
> +stat_fn_t cygwin_stat_fn = cygwin_stat_choice;
> +stat_fn_t cygwin_lstat_fn = cygwin_lstat_choice;
...
> +typedef int (*stat_fn_t)(const char*, struct stat*);
> +extern stat_fn_t cygwin_stat_fn;
> +extern stat_fn_t cygwin_lstat_fn;
extern int (*cygwin_stat_fn)(const char *, struct stat *);
Is shorter, easier to read and easier to understand (for a C person).
You don't even use the type anywhere else, it is just for the declaration sake!
^ permalink raw reply
* Re: please consider remove those tags named master, which is ambigous with master branch
From: rae l @ 2008-09-23 14:46 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Andrew Morton, git, linux-kernel
In-Reply-To: <91b13c310808310948r5e9e825as27bcdf381137e179@mail.gmail.com>
To Smurf and Andrew:
Did you notice that there's a tag named "master" in the smurf
mm-trees.git repo,
this would confuse the git and the users, please consider remove the
"master" tag, OK?
---------- Forwarded message ----------
From: rae l <crquan@gmail.com>
Date: Mon, Sep 1, 2008 at 12:48 AM
Subject: please consider remove those tags named master, which is
ambigous with master branch
To: Matthias Urlichs <smurf@smurf.noris.de>
please consider remove those tags named master, which is ambigous with
master branch
http://git.kernel.org/?p=linux/kernel/git/smurf/linux-trees.git;a=tags
--
To Git developers:
I found that different git subcommand have inconsitent processing
about ambiguous refname,
git show will take "master" tag first,
while git tag -v will take "master" branch first,
So what's your suggestion to fix this? Just simple remove ambiguous refnames?
Or we can add a feature to allow same refname in different namespaces
(tags and branches)?
Such as "-b" to refer a branch while "-t" to refer a tag name? Else
how to distinguish them?
gektop@tux ~/sforge/linux-2.6 0 $ PAGER= git show master
warning: refname 'master' is ambiguous.
commit 05230bd16821e2ec80321d72e97e7a2b1a07c6f2
Author: Adrian Bunk <bunk@stusta.de>
AuthorDate: Sat Jul 30 00:45:08 2005 +0000
Commit: Matthias Urlichs <smurf@hera.kernel.org>
CommitDate: Mon Aug 1 05:16:36 2005 -0700
sound-oss-sequencer_syms-unexport-reprogram_timer
This patch remoes an unneeded EXPORT_SYMBOL.
Signed-off-by: Andrew Morton <akpm@osdl.org>
diff --git a/sound/oss/sequencer_syms.c b/sound/oss/sequencer_syms.c
index 45edfd7..5d00879 100644
--- a/sound/oss/sequencer_syms.c
+++ b/sound/oss/sequencer_syms.c
@@ -19,7 +19,6 @@ EXPORT_SYMBOL(sequencer_timer);
EXPORT_SYMBOL(sound_timer_init);
EXPORT_SYMBOL(sound_timer_interrupt);
EXPORT_SYMBOL(sound_timer_syncinterval);
-EXPORT_SYMBOL(reprogram_timer);
/* Tuning */
gektop@tux ~/sforge/linux-2.6 0 $ git tag -v master
error: 05230bd16821e2ec80321d72e97e7a2b1a07c6f2: cannot verify a
non-tag object of type commit.
error: could not verify the tag 'master'
--
Denis Cheng Renquan
^ permalink raw reply related
* Re: clone fails: Could not get the current working directory
From: John Freeman @ 2008-09-23 14:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0809230712u4a1cbe0fo69f558cbe9a26aae@mail.gmail.com>
Alex Riesen wrote:
> Saw them. .bashrc (/etc/bashrc too) is not used for non-interactive
> sessions,
> like yours (of course, you can source them from
> .profile/.bash_login/.bash_profile).
>
> Have you tried the commands exactly? (Even more interesting would be to try
> a simple getpwd program which prints errno)
>
I have. I'm convinced that the problem is not missing commands; if it
were, I'd be getting a "missing command," or "file not found," or
similar error. Like I've said, I am able to get this to work when the
repo is in my home directory. It only fails when the repo is on another
path in the system for which I do not have read privileges all the way
down - only at the end.
- John
^ permalink raw reply
* Re: clone fails: Could not get the current working directory
From: Alex Riesen @ 2008-09-23 15:01 UTC (permalink / raw)
To: John Freeman; +Cc: git
In-Reply-To: <48D90125.3090703@cs.tamu.edu>
2008/9/23 John Freeman <jfreeman@cs.tamu.edu>:
> Alex Riesen wrote:
>>
>> Saw them. .bashrc (/etc/bashrc too) is not used for non-interactive
>> sessions,
>> like yours (of course, you can source them from
>> .profile/.bash_login/.bash_profile).
>>
>> Have you tried the commands exactly? (Even more interesting would be to
>> try
>> a simple getpwd program which prints errno)
>>
>
> I have. I'm convinced that the problem is not missing commands; if it were,
> I'd be getting a "missing command," or "file not found," or similar error.
I actually expected "ls -R" giving error about unable to read the directory
(permissions).
> Like I've said, I am able to get this to work when the repo is in my home
> directory. It only fails when the repo is on another path in the system for
> which I do not have read privileges all the way down - only at the end.
Again: try a simple program which just does getpwd for this pathname
^ permalink raw reply
* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Tor Arvid Lund @ 2008-09-23 15:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johan Herland, msysGit
In-Reply-To: <200809231554.15113.johan@herland.net>
On Tue, Sep 23, 2008 at 3:54 PM, Johan Herland <johan@herland.net> wrote:
> On Tuesday 23 September 2008, Steffen Prohaska wrote:
>> On Sep 21, 2008, at 7:33 PM, Steffen Prohaska wrote:
>> > Git-1.6.0.2-preview20080921 for Windows is available at
>> >
>> > http://code.google.com/p/msysgit/downloads
>>
>> I updated the installer to Git-1.6.0.2-preview20080923.
>> The problems reported on the mailing list during the
>> last two days should be fixed.
>
> Confirmed. SSH works again. :)
>
>> I apologize for the quality of Git-1.6.0.2-preview20080921.
>> It was unacceptable.
>
> You have absolutely nothing to apologize for. I highly appreciate the
> effort you and others put into msysGit. :)
I second that!
-Tor Arvid Lund-
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Shawn O. Pearce @ 2008-09-23 15:31 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Johannes Sixt, Junio C Hamano, Steffen Prohaska
In-Reply-To: <20080923140144.GN21650@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> This patch introduces the GIT_FAST_STAT environment variable. If this
> variable is not set then Git will work as before. However, if it is set
> then the Cygwin version of Git will try to use a Win32 API function if
> it is possible to speed up stat/lstat.
>
> This fast mode works only for relative paths. It is assumed that the
> whole repository is located inside one directory without using Cygwin
> mount to bind external paths inside of the current tree.
...
> +/*
> + * This are startup stubs, which choose what implementation of lstat/stat
> + * should be used. If GIT_FAST_STAT is not set then the standard functions
> + * included in the cygwin library are used. If it is set then our fast and
> + * dirty implementation is invoked, which should be 2-3 times faster than
> + * cygwin functions.
> + */
> +static int cygwin_stat_choice(const char *file_name, struct stat *buf)
> +{
> + cygwin_stat_fn = getenv("GIT_FAST_STAT") ?
> + cygwin_stat : stat;
> + return (*cygwin_stat_fn)(file_name, buf);
> +}
> +
> +static int cygwin_lstat_choice(const char *file_name, struct stat *buf)
> +{
> + cygwin_lstat_fn = getenv("GIT_FAST_STAT") ?
> + cygwin_lstat : lstat;
> + return (*cygwin_lstat_fn)(file_name, buf);
> +}
I wonder, should this be controlled by an environment variable?
Given your description of the feature it seems to be more a property
of the specific repository, as it is based upon where the repository
lives within the Cygwin namespace. Should this be controlled instead
by say a "core.cygwinnativestat = true" configuration property?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Dmitry Potapov @ 2008-09-23 16:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Johannes Sixt, Junio C Hamano, Steffen Prohaska
In-Reply-To: <81b0412b0809230737s7498e214w4c58991e79f76507@mail.gmail.com>
On Tue, Sep 23, 2008 at 04:37:14PM +0200, Alex Riesen wrote:
> 2008/9/23 Dmitry Potapov <dpotapov@gmail.com>:
> >
> > This fast mode works only for relative paths. It is assumed that the
> > whole repository is located inside one directory without using Cygwin
> > mount to bind external paths inside of the current tree.
>
> Why runtime conditional? Why conditional at all?
I thought that in rather unusual circumstances (such as using Cygwin
mount to connect separately directories in one tree), this fast version
may not work. So, I made it conditional. It is runtime conditional,
because most users do not build Git themselves but install a ready
Cygwin package.
> Why not fallback
> to cygwin's slow stat on absolute pathnames like you do for symlinks?
Of course, I do:
+ if (file_name[0] == '/')
+ return cygstat (file_name, buf);
Sorry, if it was not clear from my above comment.
>
> > +/*
> > + * This are startup stubs, which choose what implementation of lstat/stat
>
> why do you need two of them? Isn't one not enough?
I did not want to give people reasons to say that I broke lstat :)
You can opt for the standard Cygwin version of it if for some reason,
this new function does not work. Now, I know only one case -- it is
when you use Cygwin mount inside of Git repo. Yet, I don't know enough
about Cygwin to be sure that there is no other cases. So, I just wanted
to be extra careful and not to break anything.
>
> > +stat_fn_t cygwin_stat_fn = cygwin_stat_choice;
> > +stat_fn_t cygwin_lstat_fn = cygwin_lstat_choice;
> ...
> > +typedef int (*stat_fn_t)(const char*, struct stat*);
> > +extern stat_fn_t cygwin_stat_fn;
> > +extern stat_fn_t cygwin_lstat_fn;
>
> extern int (*cygwin_stat_fn)(const char *, struct stat *);
>
> Is shorter, easier to read and easier to understand (for a C person).
> You don't even use the type anywhere else, it is just for the declaration sake!
I use it in description of a parameter of another function:
static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
Of course, you can avoid it here too, but the declaration will become
somewhat longer:
static int do_stat(const char *file_name, struct stat *buf,
int (*cygstat)(const char *, struct stat *));
so I am not sure that removing stat_fn_t improves readability, but if
there are other people who think so, I will correct that.
Dmitry
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Dmitry Potapov @ 2008-09-23 17:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt, Junio C Hamano, Steffen Prohaska
In-Reply-To: <20080923153148.GI3669@spearce.org>
On Tue, Sep 23, 2008 at 08:31:48AM -0700, Shawn O. Pearce wrote:
>
> I wonder, should this be controlled by an environment variable?
>
> Given your description of the feature it seems to be more a property
> of the specific repository, as it is based upon where the repository
> lives within the Cygwin namespace. Should this be controlled instead
> by say a "core.cygwinnativestat = true" configuration property?
I am not sure that you will find many people who will want to set this
option per repository, yet Git has the configuration file, and I agree
it is better to place it there.
However, this option is Cygwin specific, so I am not sure where it
should be read. Should I place it in git_default_core_config like
this:
#ifdef __CYGWIN__
if (!strcmp(var, "core.cygwinnativestat")) {
cygwin_native_stat = git_config_bool(var, value);
return 0;
}
#endif
So far, we have not had any system specific options here. So, perhaps,
it is better to leave git_default_core_config alone and just replace
get_env(GIT_FAST_STAT) with git_config_bool() in the cygwin specific
code.
Dmitry
^ permalink raw reply
* Re: Locking binary files
From: Daniel Barkalow @ 2008-09-23 17:32 UTC (permalink / raw)
To: Mario Pareja; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <94c1db200809230656q4a9a765dw2354c0058b1d940c@mail.gmail.com>
On Tue, 23 Sep 2008, Mario Pareja wrote:
> > So it's a communication issue then.
>
> Yes, but I think the communication of this information needs to happen
> as part of a developers normal work-flow rather than requiring them to
> remember to check an external system.
>
> > The way I understand locks in svn
> > and cvs is that they also only bother you when you want to check in the
> > file you've just recently modified, or if multiple people want to lock
> > the same file at the same time.
>
> The SVN client will make locked files read-only until a lock is
> obtained for them. This helps "remind" you that a lock should be
> obtained before editing such a file. Requiring the developer to obtain
> a lock ensures that nobody else is editing the file and prevents
> wasted work. Upon commit, the file is marked as unlocked and the
> local file is once again read-only.
I think the right tool on the git side is actually a "smudge/clean"
script. When you check something out, git converts it from the
repository-stored form to a working tree form using a script (if there is
one configured); this could check whether you've got the appropriate lock,
and make the file unwritable if you don't. Then you have a script that
gets or releases a lock and sets any write bits on files already checked
out appropriately. There could also be locking-server magic to detect that
you've pushed a change and release the lock, telling you so that it makes
your file unwritable, but that's optional.
(Side note: consider version-specific logos; which lock you need depends
on which version you're working on, and you may want to pick up locks for
multiple versions and make changes to each logo, switching between the
branches, and make sure you can get all the locks before you start
working on any of the files, despite not having any individual file
checked out continuously in the process)
> > Note that locking would be completely advisory though, and nothing
> > would prevent people from committing changes to a locked file.
>
> If git were to support locking then it could prevent people from
> committing without first locking. Even if it is not supported
> directly by git - perhaps using a lock daemon - a wrapper would need
> to be written around git commit/push to prevent developers from
> committing/pushing changes that would cause binary merging conflicts.
If you've gotten to the point of committing (let alone pushing), and you
haven't got exclusive access, git should certainly not prevent you; the
point of the locking is to prevent people from doing work that will be
wasted, and the work is already done at this point. It's better then to
actually try the binary merge, which comes down to apologizing profusely
and then somebody openning the 3 versions (theirs, the other side's, and
the common ancestor) in their graphics program and modifying the other
side's to include their change. It wouldn't help anything to prevent
people from being able to get all of these versions to each other, once
they're made. It's also helpful to have people commit what they did before
redoing it, so that they can use it for reference in the process and won't
lose it.
(Actually, I bet it would be not-too-hard to set up gimp for three-way
merge of images; open the result file with "theirs" as the contents, and
open the common ancestor and "yours" as extra layers and set the ancestor
to negative, and make the user clean up the mess)
On the other hand, the locking server should reject your push if somebody
else has got the lock, so that the person who editted the file without
having the lock is the one stuck redoing things.
In any case, the fundamental idea is: (a) you want some server to favor
people who declare their intent to change something in advance, and give
all the work of redoing stuff to people who didn't declare their intent in
advance; and (b) you want to prompt people to declare their intent in case
they forget.
(a) is a pre-update hook that checks the diffstat against other people's
locks. (b) is a smudge script that makes files you're supposed to lock and
haven't a-w. Of course, git doesn't have the code for manipulating a
per-user set of locks, but it shouldn't be too hard to find some project
that just does that.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Eric Raible @ 2008-09-23 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <B463062F-DD48-44A7-B2BB-8E5E0D177616@zib.de>
Steffen Prohaska <prohaska <at> zib.de> writes:
>
> On Sep 21, 2008, at 7:33 PM, Steffen Prohaska wrote:
>
> > Git-1.6.0.2-preview20080921 for Windows is available at
> >
> > http://code.google.com/p/msysgit/downloads
>
> I updated the installer to Git-1.6.0.2-preview20080923.
> The problems reported on the mailing list during the
> last two days should be fixed.
>
> I apologize for the quality of Git-1.6.0.2-preview20080921.
> It was unacceptable.
>
> Steffen
Your apology is not accepted - it is us who owe thanks.
Anyway, is this expected:
/c/Documents and Settings/eric % git --version
git version 1.6.0.2.1325.gc3e64
/c/Documents and Settings/eric % git commit --help
warning: failed to exec 'man': No such file or directory
fatal: no man viewer handled the request
/c/Documents and Settings/eric % git commit --help --web
fatal: 'c:/Documents and Settings/eric/share/doc/git-doc': not a documentation
directory.
- Eric
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Jakub Narebski @ 2008-09-23 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <20080923165247.GO21650@dpotapov.dyndns.org>
Dmitry Potapov wrote:
> On Tue, Sep 23, 2008 at 04:37:14PM +0200, Alex Riesen wrote:
>> 2008/9/23 Dmitry Potapov <dpotapov@gmail.com>:
>>> +stat_fn_t cygwin_stat_fn = cygwin_stat_choice;
>>> +stat_fn_t cygwin_lstat_fn = cygwin_lstat_choice;
>> ...
>>> +typedef int (*stat_fn_t)(const char*, struct stat*);
>>> +extern stat_fn_t cygwin_stat_fn;
>>> +extern stat_fn_t cygwin_lstat_fn;
>>
>> extern int (*cygwin_stat_fn)(const char *, struct stat *);
>>
>> Is shorter, easier to read and easier to understand (for a C person).
>> You don't even use the type anywhere else, it is just for the declaration sake!
>
> I use it in description of a parameter of another function:
>
> static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
>
> Of course, you can avoid it here too, but the declaration will become
> somewhat longer:
>
> static int do_stat(const char *file_name, struct stat *buf,
> int (*cygstat)(const char *, struct stat *));
>
> so I am not sure that removing stat_fn_t improves readability, but if
> there are other people who think so, I will correct that.
I think that using typedef here definitly improves readibility.
You don't have to carefully analyse if you can pass cygwin_stat_fn
to do_stat function or not.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: rebasing merges
From: Stephen Haberman @ 2008-09-23 18:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Sixt, git
In-Reply-To: <20080923043039.bf380694.stephen@exigencecorp.com>
[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]
> > That's beside the point though, as I firmly believe git should be more
> > helpful in this situation. If "git rebase -i -p" doesn't help you fix
> > the problems, I'll see what I can do to help.
>
> That's very cool, thanks. I'll start writing a test now.
I've attached a test. You were both correct, `git rebase -i -p` keeps
the merge intact and doesn't duplicate the commits. This is awesome.
So, I'm wondering what the best way to integrate this into our workflow
is. Ideally, I think it would be great to just do:
git pull --rebase --preserve-merges
Or even better just `git pull` with branch.x.rebase=true and
branch.x.preserve-merges=true property (throw in a
branch.autosetuppreservemerges and I'll be set, haha).
While `git fetch + git rebase -i -p` will work every time, it won't be
fun to have the editor pop open, just exit it because we're not really
doing an interactive rebase, we're just borrowing its more powerful
rebase implementation, and repeat this each time a dev wants to do a
pull. Or, tell them to do a "git pull --rebase" most of the time, until
it screws up, then back up and do the other. Both doable, but not ideal.
I understand Johannes's scenario of rebasing the entire branch, and it
looks like rebase--interactive already supports this as well--e.g. if
you pass `-p`, you get our desired behavior, and if you don't pass `-p`,
you get Johannes's desired behavior of merge squashing.
Given rebase--interactive seems to be a superset of the current rebase
implementation, could the current rebase implementation just go away and
instead become a non-interactive caller (e.g. just avoid popping up the
editor with the pick list) of rebase--interactive's more powerful
rebase logic?
(Disclaimer: I'm throwing the term "more powerful" around without really
knowing whether that is true or not--for our scenario, it seems that
way, but there could be other cases I don't know about where the current
rebase implementation is superior to rebase--interactive's.)
Thanks,
Stephen
[-- Attachment #2: t3402-rebase-merge2.sh --]
[-- Type: text/x-sh, Size: 2407 bytes --]
#!/bin/sh
#
# Copyright (c) 2005 Amos Waterland
#
test_description='git rebase should not destroy author information
This test runs git rebase and checks that the author information is not lost.
'
. ./test-lib.sh
GIT_AUTHOR_EMAIL=bogus_email_address
export GIT_AUTHOR_EMAIL
echo 'Setting up:
A1--A2 <-- origin/master
\ \
B1--M <-- topic
\
B2 <-- origin/topic
'
test_expect_success 'prepare repository with topic branches' \
'echo First > A &&
git add A &&
git-commit -m "Add A1" &&
git checkout -b topic &&
echo Second > B &&
git add B &&
git-commit -m "Add B1" &&
git checkout -f master &&
echo Third >> A &&
git-commit -a -m "Modify A2" &&
git clone ./. clone1 &&
cd clone1 &&
git checkout -b topic origin/topic &&
git merge origin/master &&
cd ..
git clone ./. clone2
cd clone2 &&
git checkout -b topic origin/topic &&
git merge origin/master &&
cd .. &&
git checkout topic &&
echo Fourth >> B &&
git commit -a -m "Modify B2"
'
# Blatant copy/paste from t3404-rebase-interactive.sh--needs cleaned up
echo "#!$SHELL_PATH" >fake-editor.sh
cat >> fake-editor.sh <<\EOF
case "$1" in
*/COMMIT_EDITMSG)
test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
exit
;;
esac
test -z "$EXPECT_COUNT" ||
test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
exit
test -z "$FAKE_LINES" && exit
grep -v '^#' < "$1" > "$1".tmp
rm -f "$1"
cat "$1".tmp
action=pick
for line in $FAKE_LINES; do
case $line in
squash|edit)
action="$line";;
*)
echo sed -n "${line}s/^pick/$action/p"
sed -n "${line}p" < "$1".tmp
sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
action=pick;;
esac
done
EOF
test_set_editor "$(pwd)/fake-editor.sh"
chmod a+x fake-editor.sh
test_expect_failure 'rebase merge on moved topic' '
cd clone1 &&
git pull --rebase &&
test $(git rev-list --all --pretty=oneline | grep "Modify A" | wc -l) = 1
'
test_expect_success 'rebase -i -p merge on moved topic' '
cd ../clone2 &&
git fetch &&
FAKE_LINES="1 2" git rebase -i -p origin/topic &&
test 1 = $(git rev-list --all --pretty=oneline | grep "Modify A" | wc -l) &&
test 1 = $(git rev-list --all --pretty=oneline | grep "Merge commit" | wc -l)
'
test_done
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Johannes Sixt @ 2008-09-23 19:03 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Junio C Hamano, Steffen Prohaska
In-Reply-To: <20080923140144.GN21650@dpotapov.dyndns.org>
On Dienstag, 23. September 2008, Dmitry Potapov wrote:
> +static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
> +{
> + long long winTime = ((long long)ft->dwHighDateTime << 32) + ft->dwLowDateTime;
> + winTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */
> + ts->tv_sec = (time_t)(winTime/10000000); /* 100-nanosecond interval to seconds */
> + ts->tv_nsec = (long)(winTime - ts->tv_sec) * 100; /* nanoseconds */ +}
+ ts->tv_nsec = (long)(winTime - ts->tv_sec*10000000LL) * 100;
> +static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
> +{
> + WIN32_FILE_ATTRIBUTE_DATA fdata;
> +
> + if (file_name[0] == '/')
> + return cygstat (file_name, buf);
You should do this in the caller; it would make this function's
semantics much clearer.
> +
> + if (GetFileAttributesExA(file_name, GetFileExInfoStandard, &fdata)) {
> + int fMode = S_IREAD;
> + /*
> + * If the system attribute is set and it is not a directory then
> + * it could be a symbol link created in the nowinsymlinks mode.
> + * Normally, Cygwin works in the winsymlinks mode, so this situation
> + * is very unlikely. For the sake of simplicity of our code, let's
> + * Cygwin to handle it.
> + */
> + if ((fdata.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) &&
> + !(fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
> + return cygstat (file_name, buf);
> +
> + if (fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
> + fMode |= S_IFDIR;
> + else
> + fMode |= S_IFREG;
> + if (!(fdata.dwFileAttributes & FILE_ATTRIBUTE_READONLY))
> + fMode |= S_IWRITE;
> +
> + /* st_dev, st_rdev are not used by Git */
> + buf->st_dev = buf->st_rdev = 0;
> + /* it is difficult to obtain the inode number on Windows,
> + * so let's set it to zero as MinGW Git does. */
> + buf->st_ino = 0;
> + buf->st_mode = fMode;
> + buf->st_nlink = 1;
> + buf->st_uid = buf->st_gid = 0;
> +#ifdef __CYGWIN_USE_BIG_TYPES__
> + buf->st_size = ((_off64_t)fdata.nFileSizeHigh << 32) +
> + fdata.nFileSizeLow;
> +#else
> + buf->st_size = (off_t)fdata.nFileSizeLow;
> +#endif
> + buf->st_blocks = size_to_blocks(buf->st_size);
> + filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
> + filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
> + filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
> + errno = 0;
> + return 0;
> + }
> +
> + switch (GetLastError()) {
> + case ERROR_ACCESS_DENIED:
> + case ERROR_SHARING_VIOLATION:
> + case ERROR_LOCK_VIOLATION:
> + case ERROR_SHARING_BUFFER_EXCEEDED:
> + errno = EACCES;
> + break;
> + case ERROR_BUFFER_OVERFLOW:
> + errno = ENAMETOOLONG;
> + break;
> + case ERROR_NOT_ENOUGH_MEMORY:
> + errno = ENOMEM;
> + break;
> + default:
> + /* In the winsymlinks mode (which is the default), Cygwin
> + * emulates symbol links using Windows shortcut files. These
> + * files are formed by adding .lnk extension. So, if we have
> + * not found the specified file name, it could be that it is
> + * a symbol link. Let's Cygwin to deal with that.
> + */
> + return cygstat (file_name, buf);
> + }
> + return -1;
You do duplicate a lot of code here. Any chances to factor out the
common parts? Start with platform specific function
filetime_to_stat_time() that is your filetime_to_timespec() on Cygwin,
but filetime_to_time_t() (which needs modification) on MinGW.
-- Hannes
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Shawn O. Pearce @ 2008-09-23 19:06 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Johannes Sixt, Junio C Hamano, Steffen Prohaska
In-Reply-To: <20080923171209.GP21650@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Sep 23, 2008 at 08:31:48AM -0700, Shawn O. Pearce wrote:
> >
> > I wonder, should this be controlled by an environment variable?
> >
> > Given your description of the feature it seems to be more a property
> > of the specific repository, as it is based upon where the repository
> > lives within the Cygwin namespace. Should this be controlled instead
> > by say a "core.cygwinnativestat = true" configuration property?
>
> I am not sure that you will find many people who will want to set this
> option per repository, yet Git has the configuration file, and I agree
> it is better to place it there.
If you want it globally you can do:
git config --global core.cygwinnativestat true
and then disable it on a per-repository basis if you and a specific
repository which has this inner mount problem:
git config core.cygwinnativestat false
Which is a lot more powerful than an environment variable.
> However, this option is Cygwin specific, so I am not sure where it
> should be read. Should I place it in git_default_core_config like
> this:
>
> #ifdef __CYGWIN__
> if (!strcmp(var, "core.cygwinnativestat")) {
> cygwin_native_stat = git_config_bool(var, value);
> return 0;
> }
> #endif
I would have the two initial stat functions swap themselves out with
the default Cygin stat implementations, run a parse over the config
to load that one bool, then install the proper implementations based
upon its value. Hence all Cygwin code is kept inside of the Cygwin
compat code, and no #ifdef is necessary
Of course that config file parse can only happen after the repository
has been entered, which means you need to somehow rely on the real
Cygwin stat functions until setup_git_directory() has completed,
and then on the next stat call (re)parse the config and swap the
implementation.
--
Shawn.
^ permalink raw reply
* fatal: cannot store pack file (git 1.6.0.2 + sshfs)
From: Jhair Tocancipa Triana @ 2008-09-23 19:15 UTC (permalink / raw)
To: git
I'm getting the following when running git on a partition mounted with
sshfs:
$ git pull
remote: Counting objects: 304, done.
remote: Compressing objects: 100% (256/256), done.
remote: Total 260 (delta 103), reused 0 (delta 0)
Receiving objects: 100% (260/260), 26.62 MiB | 3979 KiB/s, done.
Resolving deltas: 100% (103/103), completed with 32 local objects.
error: unable to write sha1 filename .git/objects/pack/pack-dc5c3614e795918f457a2f98a58f10134ebf246b.pack: Operation not permitted
fatal: cannot store pack file
fatal: index-pack failed
git pull worked fine in the same repository yesterday (new files where
committed in the meantime).
I'm not sure if this is a problem in git or in sshfs (or somewhere
else).
Any ideas what the problem could be?
Thanks,
--
Jhair
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Dmitry Potapov @ 2008-09-23 19:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Steffen Prohaska
In-Reply-To: <200809232103.09133.johannes.sixt@telecom.at>
On Tue, Sep 23, 2008 at 09:03:08PM +0200, Johannes Sixt wrote:
> On Dienstag, 23. September 2008, Dmitry Potapov wrote:
> > +static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
> > +{
> > + long long winTime = ((long long)ft->dwHighDateTime << 32) + ft->dwLowDateTime;
> > + winTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */
> > + ts->tv_sec = (time_t)(winTime/10000000); /* 100-nanosecond interval to seconds */
> > + ts->tv_nsec = (long)(winTime - ts->tv_sec) * 100; /* nanoseconds */ +}
>
> + ts->tv_nsec = (long)(winTime - ts->tv_sec*10000000LL) * 100;
Thanks.... What was I thought about when wrote this....
>
> > +static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
> > +{
> > + WIN32_FILE_ATTRIBUTE_DATA fdata;
> > +
> > + if (file_name[0] == '/')
> > + return cygstat (file_name, buf);
>
> You should do this in the caller; it would make this function's
> semantics much clearer.
IMHO, the semantic of this function is clear: do_stat performs stat/lstat
using Windows API with falling back on Cygwin implementation in those
rare cases that it cannot handle correctly. Absolute path is just one of
those cases. So, I am not sure what you win by moving this two lines out.
> > + if (GetFileAttributesExA(file_name, GetFileExInfoStandard, &fdata)) {
> > + int fMode = S_IREAD;
> > + /*
> > + * If the system attribute is set and it is not a directory then
> > + * it could be a symbol link created in the nowinsymlinks mode.
> > + * Normally, Cygwin works in the winsymlinks mode, so this situation
> > + * is very unlikely. For the sake of simplicity of our code, let's
> > + * Cygwin to handle it.
> > + */
> > + if ((fdata.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) &&
> > + !(fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
> > + return cygstat (file_name, buf);
This is specific to cygwin.
> > +
> > + if (fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
> > + fMode |= S_IFDIR;
> > + else
> > + fMode |= S_IFREG;
> > + if (!(fdata.dwFileAttributes & FILE_ATTRIBUTE_READONLY))
> > + fMode |= S_IWRITE;
These lines the same as mingw
> > +
> > + /* st_dev, st_rdev are not used by Git */
> > + buf->st_dev = buf->st_rdev = 0;
I set this to 0, while MinGW Git uses _getdrive(). I have no idea why
it does so. Git does not use this field, and if it did, adding the
_current_ drive number is useless at best when we are trying to
determine whether the file is changed or not.
> > + /* it is difficult to obtain the inode number on Windows,
> > + * so let's set it to zero as MinGW Git does. */
> > + buf->st_ino = 0;
> > + buf->st_mode = fMode;
> > + buf->st_nlink = 1;
> > + buf->st_uid = buf->st_gid = 0;
This is the same as for MinGW
> > +#ifdef __CYGWIN_USE_BIG_TYPES__
> > + buf->st_size = ((_off64_t)fdata.nFileSizeHigh << 32) +
> > + fdata.nFileSizeLow;
> > +#else
> > + buf->st_size = (off_t)fdata.nFileSizeLow;
> > +#endif
> > + buf->st_blocks = size_to_blocks(buf->st_size);
> > + filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
> > + filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
> > + filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
This is different: using 64-bit version for st_size, st_blocks does not
exist in MinGW, and finally filetime_to_timespec instead of filetime_to_time_t,
as well as the name of fields is different (st_ctim instead of st_ctime, etc).
> > + errno = 0;
> > + return 0;
> > + }
> > +
> > + switch (GetLastError()) {
> > + case ERROR_ACCESS_DENIED:
> > + case ERROR_SHARING_VIOLATION:
> > + case ERROR_LOCK_VIOLATION:
> > + case ERROR_SHARING_BUFFER_EXCEEDED:
> > + errno = EACCES;
> > + break;
> > + case ERROR_BUFFER_OVERFLOW:
> > + errno = ENAMETOOLONG;
> > + break;
> > + case ERROR_NOT_ENOUGH_MEMORY:
> > + errno = ENOMEM;
> > + break;
> > + default:
> > + /* In the winsymlinks mode (which is the default), Cygwin
> > + * emulates symbol links using Windows shortcut files. These
> > + * files are formed by adding .lnk extension. So, if we have
> > + * not found the specified file name, it could be that it is
> > + * a symbol link. Let's Cygwin to deal with that.
> > + */
> > + return cygstat (file_name, buf);
> > + }
This is the same as in MinGW, except the default case, where MinGW
returns error immediately while this version calls the fallback
function.
> > + return -1;
>
> You do duplicate a lot of code here. Any chances to factor out the
> common parts?
I don't see much common code here. Initialization of 5 variables where
four of them are just constants? Perhaps, the biggest common part here
is conversion of dwFileAttributes to st_mode, but it is still 5 lines of
trivial code.
Dmitry
^ permalink raw reply
* Re: Locking binary files
From: Junio C Hamano @ 2008-09-23 19:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Mario Pareja, Andreas Ericsson, Git Mailing List
In-Reply-To: <alpine.LNX.1.00.0809231216350.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I think the right tool on the git side is actually a "smudge/clean"
> script. When you check something out, git converts it from the
> repository-stored form to a working tree form using a script (if there is
> one configured); this could check whether you've got the appropriate lock,
> and make the file unwritable if you don't.
An obvious question is "how would such a script check the lock when you
are 30,000 ft above ground"; in other words, this "locking mechanism"
contradicts the very nature of distributed development theme. The best
mechanism should always be on the human side. An SCM auguments
inter-developer communication, but it is not a _substitute_ for
communication.
But if you limit the use case to an always tightly connected environment
(aka "not distributed at all"), I agree the above would be a very
reasonable approach.
Such a setup would need a separate locking infrastructure and an end user
command that grabs the lock and when successful makes the file in the work
tree read/write. The user butchers the contents after taking the lock,
saves, and then when running "git commit", probably the post-commit hook
would release any relevant locks.
All these can be left outside the scope of git, as they can be hooked into
git with the existing infrastructure. Once a BCP materializes it could be
added to contrib/ just like the "paranoid" update hook.
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Dmitry Potapov @ 2008-09-23 20:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt, Junio C Hamano, Steffen Prohaska
In-Reply-To: <20080923190637.GJ3669@spearce.org>
On Tue, Sep 23, 2008 at 12:06:37PM -0700, Shawn O. Pearce wrote:
>
> and then disable it on a per-repository basis if you and a specific
> repository which has this inner mount problem:
>
> git config core.cygwinnativestat false
>
> Which is a lot more powerful than an environment variable.
I already said that I completely agree that is a good idea even I don't
know the real need for having per-repository configuration in practice.
>
> > However, this option is Cygwin specific, so I am not sure where it
> > should be read. Should I place it in git_default_core_config like
> > this:
> >
> > #ifdef __CYGWIN__
> > if (!strcmp(var, "core.cygwinnativestat")) {
> > cygwin_native_stat = git_config_bool(var, value);
> > return 0;
> > }
> > #endif
>
> I would have the two initial stat functions swap themselves out with
> the default Cygin stat implementations, run a parse over the config
> to load that one bool, then install the proper implementations based
> upon its value. Hence all Cygwin code is kept inside of the Cygwin
> compat code, and no #ifdef is necessary
Do I understand you correctly that you propose to add the code like
this in compat/cygwin.c:
static int native_stat;
static int git_cygwin_config(const char *var, const char *value, void
*cb)
{
if (!strcmp(var, "core.cygwinnativestat"))
cygwin_native_stat = git_config_bool(var, value);
return 0;
}
static void init_stat(void)
{
git_config(git_cygwin_config, NULL);
cygwin_stat_fn = native_stat ? cygwin_stat : stat;
cygwin_lstat_fn = native_stat ? cygwin_lstat : lstat;
}
static int cygwin_stat_choice(const char *file_name, struct stat *buf)
{
init_stat();
return (*cygwin_stat_fn)(file_name, buf);
}
static int cygwin_lstat_choice(const char *file_name, struct stat *buf)
{
init_stat();
return (*cygwin_lstat_fn)(file_name, buf);
}
Dmitry
^ permalink raw reply
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Shawn O. Pearce @ 2008-09-23 20:17 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Johannes Sixt, Junio C Hamano, Steffen Prohaska
In-Reply-To: <20080923200456.GR21650@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> Do I understand you correctly that you propose to add the code like
> this in compat/cygwin.c:
Yes. But with minor changes (see below):
> static int native_stat;
static int native_stat = -1;
> static int git_cygwin_config(const char *var, const char *value, void
> *cb)
> {
> if (!strcmp(var, "core.cygwinnativestat"))
> cygwin_native_stat = git_config_bool(var, value);
> return 0;
> }
>
> static void init_stat(void)
> {
> git_config(git_cygwin_config, NULL);
> cygwin_stat_fn = native_stat ? cygwin_stat : stat;
> cygwin_lstat_fn = native_stat ? cygwin_lstat : lstat;
if (native_stat < 0 && have_git_dir()) {
native_stat = 0;
git_config(git_cygwin_config, NULL);
cygwin_stat_fn = native_stat ? cygwin_stat : stat;
cygwin_lstat_fn = native_stat ? cygwin_lstat : lstat;
}
and then you have to define have_git_dir() inside environment.c as:
int have_git_dir(void)
{
return !!git_dir;
}
> static int cygwin_stat_choice(const char *file_name, struct stat *buf)
> {
> init_stat();
> return (*cygwin_stat_fn)(file_name, buf);
> }
>
> static int cygwin_lstat_choice(const char *file_name, struct stat *buf)
> {
> init_stat();
> return (*cygwin_lstat_fn)(file_name, buf);
> }
--
Shawn.
^ permalink raw reply
* [EGIT PATCH] Push and fetch icons for the toolbar
From: Robin Rosenberg @ 2008-09-23 20:19 UTC (permalink / raw)
To: spearce; +Cc: Marek Zawirski, git
[-- Attachment #1: Type: text/plain, Size: 5777 bytes --]
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
PS. I attached the enabled versions of the icons just in case your email
reader doesn't display images from git binary patches. DS.
org.spearce.egit.ui/icons/toolbar/fetchd.png | Bin 0 -> 359 bytes
org.spearce.egit.ui/icons/toolbar/fetche.png | Bin 0 -> 393 bytes
org.spearce.egit.ui/icons/toolbar/pushd.png | Bin 0 -> 372 bytes
org.spearce.egit.ui/icons/toolbar/pushe.png | Bin 0 -> 404 bytes
org.spearce.egit.ui/plugin.xml | 32 ++++++++++++++-----------
5 files changed, 18 insertions(+), 14 deletions(-)
create mode 100644 org.spearce.egit.ui/icons/toolbar/fetchd.png
create mode 100644 org.spearce.egit.ui/icons/toolbar/fetche.png
create mode 100644 org.spearce.egit.ui/icons/toolbar/pushd.png
create mode 100644 org.spearce.egit.ui/icons/toolbar/pushe.png
diff --git a/org.spearce.egit.ui/icons/toolbar/fetchd.png b/org.spearce.egit.ui/icons/toolbar/fetchd.png
new file mode 100644
index 0000000000000000000000000000000000000000..4433c543f2a52b586a3ed5e31b138244107bc239
GIT binary patch
literal 359
zcmV-t0hs=YP)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV0003lNkl<ZIE|%~
zF{;8q6h+U7BBn4qm_`dxuy6}@!NzsCfLTKp;5yPsN=p|I(rKe&p~M74Bq5ObRRW{%
zje4sYc=ybGk2gYV%`a+{hvjnl6{!Lo4hNJ{A44jDl#(C_K2BmJ09dV7A3>VW2}+n!
zO1rKr0DRxqm&=7b&q>piUayDaIKlvw2}+e_&-3(PFkmzq(Q380-|r+zg6Da9KA(#Q
zPa2QMl^Gz*GK3HmMPby1VQ9_(U^bf>W`H=3+3)uhMZxuY<#al++wJIfyXFi47K?>p
z2GCj~rNp*vI-L&fb{osGh@!|$@ci;S2_arv_(sil1xb<+1Odb0kjLY}`F!ShJaW6;
z>Lr*?r);;|7ihoV2SC*MjhoFzuh;A9KAB9aMXCk(Pk$Loi}X0uxcmSB002ovPDHLk
FV1lxPoI3yj
literal 0
HcmV?d00001
diff --git a/org.spearce.egit.ui/icons/toolbar/fetche.png b/org.spearce.egit.ui/icons/toolbar/fetche.png
new file mode 100644
index 0000000000000000000000000000000000000000..0ffeb419e6ab302caa5e58661854b33853dc43dc
GIT binary patch
literal 393
zcmV;40e1e0P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV0003{Nkl<ZIE|%}
z%Su8~6o$WjJd|h&)kLg8qatclklHDbhzOh%4SI>*L3{^aqJcvRqCsRQ6~SndH7ExK
zk=KcyE?#y6(aupYt$(ujUi|ChXYD1Vl>A3Z=W-tL|B2KE=%pm#uoxNA1!yxqxEMW&
zB>{jQO^yT+ogtn_{8Ep$Aq3h-C?o|y>g-6?-!e46K4}{7I2X6^?w$w$wKqXWo#uE<
zlN$@u$mIiCW0N$hIYc2#Jf_L5pe_`875HfeP>nhW1zLv1R!iSvNdTZ7`q(*62#YbV
zQhB;#V#z_Hl;tD;jPm%3!!_Fv=xqj&EpW_lqPo^m>_wFE9KxQ3t1@8v1#@h(gk?2k
zU%h_@BTD_vVB{6b=^Lij^3<ya#!DI7eU*yg9xg#(&qL<HX{n_QH=dOmU|OU>Dkk>j
n^=YB|UiI3T3toz$0fY1nZ1068v8@+b00000NkvXXu0mjfWwNMg
literal 0
HcmV?d00001
diff --git a/org.spearce.egit.ui/icons/toolbar/pushd.png b/org.spearce.egit.ui/icons/toolbar/pushd.png
new file mode 100644
index 0000000000000000000000000000000000000000..22c3f7bf17b8b5a931c7527d768af13607b03bce
GIT binary patch
literal 372
zcmV-)0gL{LP)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV0003yNkl<ZIE|%~
zF{%PF6h%)&8w)Kgg)~~o6c%=-wG$iH;R0NP3veAG$Sh>A(?&%>K?5S92zkHxGyeyN
zQSnxRymxZ%OQJ-CZ<LQ0VHnEcaNzNHaJ${8)oOIRUG)l}M1;v?B8^6aVzEe}P~dX8
zV6A1h+tKg$Ga)&E`~8km3g?`+IiJs8M#ur2PA68Y70x-1$0OVAmgRCusZ@FoAR=h3
zDVNJsDix~LD)oBZD;$r<sngD7(Utm(zh18y4u?;WOu&C>t%;)O$w?l-T1yl~1VO;{
zdS$=gv)ODopU<8HfZ1#YAcMg`B@Q~B4vWRYJJDL}%|UCO8Yd6XZnu?)$aFeQidwCf
z_mE--u|}hjN&o=H7-fukIg4hqnKXNVchu|kh_lCf`xbzwX88RJ-{>O;Y5D>6^@Sy#
SDlMe|0000<MNUMnLSTZnn4{zX
literal 0
HcmV?d00001
diff --git a/org.spearce.egit.ui/icons/toolbar/pushe.png b/org.spearce.egit.ui/icons/toolbar/pushe.png
new file mode 100644
index 0000000000000000000000000000000000000000..1f99f0a702983d674f15eedae5f1218f0a30b5a0
GIT binary patch
literal 404
zcmV;F0c-w=P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00047Nkl<ZIE|%~
z%Su8~6o$WjJO~|4C>w|sG%6%VHSk(UL<B+v4SI>*L41dvA&3Z?G>L*BB*n0rWDTl8
zL8Pb?Jzc!)CSJ}#$rF8}#a?Uu`(JCbg_M&2pmu`H$+oP&=V*R^(bPY1%&ibu+ZV$G
zgp`tt<A@B;jw3Z6E&C{q>NBF4=c=f%6i@vsq5!CR9fSfc-IT0lZ>^0`E2vbS?r{1v
z8l^m+g%^~^H#FDePyq!%wm_SSqPmu`yJKk6QAXzdroz+R(7<gg074jZz1Vo3Dy2y#
zMW2W=)MJ~7I|%3fPE-KBpis_UGqzZuUe(cG%h>L#RCJHY0YK_74TR+C&ZX!&h^>3c
zJvdA^W^@l;f6eS*z&I*^D|{frVpE>&7273F76LY=;y1$BWF(Q0qALI}5jqkZAq&fh
y^_oorR)}l`>CE22@+$y+&Cvb}|KU##2Jr)k?t0Dap2#Es0000<MNUMnLSTZgH?cGT
literal 0
HcmV?d00001
diff --git a/org.spearce.egit.ui/plugin.xml b/org.spearce.egit.ui/plugin.xml
index 7c98688..ee8a5a0 100644
--- a/org.spearce.egit.ui/plugin.xml
+++ b/org.spearce.egit.ui/plugin.xml
@@ -272,22 +272,26 @@
</separator>
</menu>
<action
- class="org.spearce.egit.ui.internal.actions.FetchAction"
- id="org.spearce.egit.ui.actionfetch"
- label="%FetchAction_label"
- style="push"
- menubarPath="org.spearce.egit.ui.gitmenu/repo"
- toolbarPath="org.spearce.egit.ui"
- tooltip="%FetchAction_tooltip">
+ class="org.spearce.egit.ui.internal.actions.FetchAction"
+ disabledIcon="icons/toolbar/fetchd.png"
+ icon="icons/toolbar/fetche.png"
+ id="org.spearce.egit.ui.actionfetch"
+ label="%FetchAction_label"
+ menubarPath="org.spearce.egit.ui.gitmenu/repo"
+ style="push"
+ toolbarPath="org.spearce.egit.ui"
+ tooltip="%FetchAction_tooltip">
</action>
<action
- class="org.spearce.egit.ui.internal.actions.PushAction"
- id="org.spearce.egit.ui.actionpush"
- label="%PushAction_label"
- style="push"
- menubarPath="org.spearce.egit.ui.gitmenu/repo"
- toolbarPath="org.spearce.egit.ui"
- tooltip="%PushAction_tooltip">
+ class="org.spearce.egit.ui.internal.actions.PushAction"
+ disabledIcon="icons/toolbar/pushd.png"
+ icon="icons/toolbar/pushe.png"
+ id="org.spearce.egit.ui.actionpush"
+ label="%PushAction_label"
+ menubarPath="org.spearce.egit.ui.gitmenu/repo"
+ style="push"
+ toolbarPath="org.spearce.egit.ui"
+ tooltip="%PushAction_tooltip">
</action>
<action
class="org.spearce.egit.ui.internal.actions.BranchAction"
--
1.6.0.1.310.gf789d0
[-- Attachment #2: fetche.png --]
[-- Type: image/png, Size: 393 bytes --]
[-- Attachment #3: pushe.png --]
[-- Type: image/png, Size: 404 bytes --]
^ permalink raw reply related
* Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Johannes Sixt @ 2008-09-23 20:41 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Junio C Hamano, Steffen Prohaska
In-Reply-To: <20080923194802.GQ21650@dpotapov.dyndns.org>
On Dienstag, 23. September 2008, Dmitry Potapov wrote:
> On Tue, Sep 23, 2008 at 09:03:08PM +0200, Johannes Sixt wrote:
> > On Dienstag, 23. September 2008, Dmitry Potapov wrote:
> > > +static int do_stat(const char *file_name, struct stat *buf, stat_fn_t
> > > cygstat) +{
> > > + WIN32_FILE_ATTRIBUTE_DATA fdata;
> > > +
> > > + if (file_name[0] == '/')
> > > + return cygstat (file_name, buf);
> >
> > You should do this in the caller; it would make this function's
> > semantics much clearer.
>
> IMHO, the semantic of this function is clear: do_stat performs stat/lstat
> using Windows API with falling back on Cygwin implementation in those
> rare cases that it cannot handle correctly. Absolute path is just one of
> those cases. So, I am not sure what you win by moving this two lines out.
You copied the function from compat/mingw.c. There it has the meaning "Fill in
struct stat using Win32 API" and nothing else. Here it has the meaning "Fill
in struct stat using Win32 API if you can, and using cygstat() in certain
exceptional cases". If you stayed with the original meaning, it would be
slightly easier to factor out common code.
> > > + /* st_dev, st_rdev are not used by Git */
> > > + buf->st_dev = buf->st_rdev = 0;
>
> I set this to 0, while MinGW Git uses _getdrive(). I have no idea why
> it does so.
Indeed. Calling _getdrive() is absolutely useless.
> > You do duplicate a lot of code here. Any chances to factor out the
> > common parts?
>
> I don't see much common code here. Initialization of 5 variables where
> four of them are just constants? Perhaps, the biggest common part here
> is conversion of dwFileAttributes to st_mode, but it is still 5 lines of
> trivial code.
Sigh. I gave a pointer how to unify the two functions (although I missed the
fact that the member variables are named differently). I'd appreciate if you
did not make it more difficult than necessary to factor out common code.
-- Hannes
^ 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