* [PATCH] Allow updating the index from a pipe
From: Daniel Barkalow @ 2005-12-10 6:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In order to allow the index to be modified in simple ways without
having a working tree, this adds an option to git-update-index which
updates a single path with a mode of 100644 and reads the content from
stdin. Somebody should probably give the option a better name.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
This is for a git-backed wiki I'm writing, which doesn't want to use a
working tree when preparing changes, but wants to work entirely with pipes
and index files.
Documentation/git-update-index.txt | 7 ++++++
cache.h | 1 +
sha1_file.c | 27 ++++++++++++++++++++++++
update-index.c | 40 +++++++++++++++++++++++++++++++++++-
4 files changed, 74 insertions(+), 1 deletions(-)
7883add98deb548c7c10681ae3d71b7a7d949a9a
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index e4678cd..d35340a 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -14,6 +14,7 @@ SYNOPSIS
[--cacheinfo <mode> <object> <file>]\*
[--chmod=(+|-)x]
[--info-only] [--index-info]
+ [--name=<file>]
[-z] [--stdin]
[--verbose]
[--] [<file>]\*
@@ -87,6 +88,12 @@ OPTIONS
read list of paths from the standard input. Paths are
separated by LF (i.e. one path per line) by default.
+--name=<file>::
+ Instead of taking a list of paths, only operate on a single
+ path, and get the content from the standard input instead of
+ from the file system. The mode for the file will be 100644
+ (regular non-executable file).
+
--verbose::
Report what is being added and removed from index.
diff --git a/cache.h b/cache.h
index 86fc250..1b30f44 100644
--- a/cache.h
+++ b/cache.h
@@ -144,6 +144,7 @@ extern int ce_match_stat(struct cache_en
extern int ce_modified(struct cache_entry *ce, struct stat *st);
extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);
extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type);
+extern int index_pipe(unsigned char *sha1, int fd, const char *type);
extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
diff --git a/sha1_file.c b/sha1_file.c
index 111a71d..0073187 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1528,6 +1528,33 @@ int has_sha1_file(const unsigned char *s
return find_sha1_file(sha1, &st) ? 1 : 0;
}
+int index_pipe(unsigned char *sha1, int fd, const char *type)
+{
+ unsigned long size = 4096;
+ char *buf = malloc(size);
+ int iret, ret;
+ unsigned long off = 0;
+ do {
+ iret = read(fd, buf + off, size - off);
+ if (iret > 0) {
+ off += iret;
+ if (off == size) {
+ size *= 2;
+ buf = realloc(buf, size);
+ }
+ }
+ } while (iret > 0);
+ if (iret < 0) {
+ free(buf);
+ return -1;
+ }
+ if (!type)
+ type = "blob";
+ ret = write_sha1_file(buf, off, type, sha1);
+ free(buf);
+ return ret;
+}
+
int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type)
{
unsigned long size = st->st_size;
diff --git a/update-index.c b/update-index.c
index 11b7f6a..f3d79af 100644
--- a/update-index.c
+++ b/update-index.c
@@ -24,6 +24,8 @@ static int info_only;
static int force_remove;
static int verbose;
+static char *single_name = NULL;
+
/* Three functions to allow overloaded pointer return; see linux/err.h */
static inline void *ERR_PTR(long error)
{
@@ -117,6 +119,33 @@ static int add_file_to_cache(const char
return 0;
}
+
+static int add_stdin_to_cache(const char *path)
+{
+ int size, namelen, option;
+ struct cache_entry *ce;
+ struct stat st;
+
+ namelen = strlen(path);
+ size = cache_entry_size(namelen);
+ ce = xmalloc(size);
+ memset(ce, 0, size);
+ memcpy(ce->name, path, namelen);
+ ce->ce_mode = create_ce_mode(0100644);
+ ce->ce_flags = create_ce_flags(namelen, 0);
+
+ st.st_size = 0;
+
+ if (index_pipe(ce->sha1, 0, NULL))
+ return -1;
+ option = allow_add ? ADD_CACHE_OK_TO_ADD : 0;
+ option |= allow_replace ? ADD_CACHE_OK_TO_REPLACE : 0;
+ if (add_cache_entry(ce, option))
+ return error("%s: cannot add to the index - missing --add option?",
+ path);
+ return 0;
+}
+
/*
* "refresh" does not calculate a new sha1 file or bring the
* cache up-to-date for mode/content changes. But what it
@@ -396,7 +425,7 @@ static void read_index_info(int line_ter
}
static const char update_index_usage[] =
-"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--cacheinfo] [--chmod=(+|-)x] [--info-only] [--force-remove] [--stdin] [--index-info] [--ignore-missing] [-z] [--verbose] [--] <file>...";
+"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--cacheinfo] [--chmod=(+|-)x] [--info-only] [--force-remove] [--stdin] [--index-info] [--ignore-missing] [--name=<file>] [-z] [--verbose] [--] <file>...";
int main(int argc, const char **argv)
{
@@ -464,6 +493,10 @@ int main(int argc, const char **argv)
die("git-update-index: %s cannot chmod %s", path, argv[i]);
continue;
}
+ if (!strncmp(path, "--name=", strlen("--name="))) {
+ single_name = strdup(path + strlen("--name="));
+ continue;
+ }
if (!strcmp(path, "--info-only")) {
info_only = 1;
continue;
@@ -499,6 +532,8 @@ int main(int argc, const char **argv)
usage(update_index_usage);
die("unknown option %s", path);
}
+ if (single_name)
+ die("--name=<file> is incompatible with filenames");
update_one(path, prefix, prefix_length);
}
if (read_from_stdin) {
@@ -511,6 +546,9 @@ int main(int argc, const char **argv)
update_one(buf.buf, prefix, prefix_length);
}
}
+ if (single_name) {
+ add_stdin_to_cache(single_name);
+ }
if (active_cache_changed) {
if (write_cache(newfd, active_cache, active_nr) ||
commit_index_file(&cache_file))
--
0.99.9.GIT
^ permalink raw reply related
* Re: as promised, docs: git for the confused
From: Junio C Hamano @ 2005-12-10 1:22 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20051209054401.4016.qmail@science.horizon.com>
linux@horizon.com writes:
> .... There has
> been motion towards putting the git-* commands in their own directory,
> to be invoked by the /usr/bin/git wrapper.
>
> In this case, you'll have to leave out the initial hyphen, or add the
> git binary directory to your $PATH.
Misleading, if not incorrect. git wrapper and a handful others
such as receive-pack and upload-pack that need to be directly
invoked via ssh will remain in /usr/bin and the users do not
need to worry about where the rest went. The recommended way
would be to use non-dash form. If you care about the extra
indirection done by "git" in your script, run "git --exec-path"
once to get the git binary directory and prepend the result to
PATH. You _could_ do the latter for your interactive shell
session as well, but it is not actively recommended.
> * Resetting
>
> There are actually three kinds of git-reset:
> git-reset --soft: Only overwrite the reference. If you need to, you
> can put everything back with a second git-reset --soft OLD_HEAD.
I am not sure what you mean by "second" here. Did you mean to
say something like this?
After you did "git-reset --soft somewhereyoudidnotmeantogo"
by mistake, you can recover with "git-reset --soft ORIG_HEAD".
> There is an undelete: git-reset stores the previous HEAD commit in
> OLD_HEAD.
And probably you meant to say ORIG_HEAD (the latter part of the
documentation you do say ORIG_HEAD).
Now I finally had a chance to finish the command list part.
> git-prune.sh
>...
> eliminate the
Incomplete sentence.
> git-pack-objects
> Given a list of objects on stdin, build a pack file. This is
> a helper used by the various network communication scripts.
... and by (obviously) git-repack.
> + Accepting changes by e-mail
> git-apply
> Apply a (git-style extended) patch to the current index
> and working directory.
Actually it can take "patch -p1" format patch, and the input
does not have to be git-extended patch. Two extra things you
can do when the input is git-extended patch is to apply
rename/copy and filemode changes.
> git-merge-base
>...
> somewhat hairy. The algorithm is not 100% final yet.
I do not think there is any remaining issues with the current
algorithm, so you can mark it final now.
> git-mktag
> Creates a tag object. Verifies syntactic correctness of its
> input. (If you want to cheat, use git-hash-object.)
Is there a particular reason to encourage cheating? IOW, is
mktag cumbersome to use, and if so how?
> git-local-fetch
> Duplicates a git repository from the local system.
> (Er... is this used anywhere???)
Not by git barebone Porcelain, but other Porcelains can use it
if they want. Same thing for git-ssh-fetch.
> git-ssh-pull
> A helper program that pulls over ssh.
git-ssh-pull and git-ssh-fetch are the same program, and the
former is only for backward compatibility. Earlier, only
git-ssh-pull/git-ssh-push pair existed and they continue to
invoke the other on the other end. Terminology standardized to
call downloading phase "-fetch", and its counterpart "-upload";
so git-ssh-fetch invokes git-ssh-upload on the other end (so
ssh-pull/ssh-push can be viewed obsolete if you want).
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Junio C Hamano @ 2005-12-09 23:23 UTC (permalink / raw)
To: linux; +Cc: junkio, git
In-Reply-To: <20051209215414.14072.qmail@science.horizon.com>
linux@horizon.com writes:
> Some users want to track someone else's repository.
> Others...
Exactly. That's why task oriented list would be most useful.
Here is a starter.
Everyday GIT Cheat Sheet Or Git With 20 Commands
================================================
Repository Administration
-------------------------
* "init-db" or "clone" to create the initial repository.
* hooks.
- public accessible via dumb protocols: need
update-server-info in hooks/post-update
- CVS style shared repository: see howto/update-hook-example
for ideas on branch head policy
* "fsck-objects", "repack" and "prune".
Individual Developer
--------------------
Standalone tasks
* "show-branch" or "gitk" to see where you are.
* "diff" or "status" to see what you are in the middle of.
* "log" to see what happened.
* "whatchanged" to find out where things come from.
* "checkout" and "checkout -b" to switch branches.
* "commit" to advance the current branch head.
* "reset" to undo unpublished changes.
* "checkout -- path" to undo working tree chanegs.
* "pull ." to merge between branches.
* "rebase" to maintain topic branches.
* "fsck-objects", "repack" and "prune".
Working as a participant
* all the commands useful for standalone individual developer tasks.
* "pull origin" to keep up-to-date.
* "push upstream" in CVS style shared repository workflow.
* "format-patch" in kernel style public forum workflow.
Integrator
----------
* all the commands useful for standalone individual developer tasks.
* "am" to apply patches.
* "pull somewhere-else" to merge from trusted lieutenants.
* "format-patch" to send suggested alternative to contributors.
* "revert" to undo botched changes.
* "push public" to publish the results.
It might be surprising that only handful commands are of
everyday use among 100+, but the ones listed above are the only
ones I use every day. The exact number depends on how you count
multi-purpose commands like "checkout" and "pull", but only
these need to be learned to play all roles listed above.
am
checkout
checkout -- path
checkout -b
commit
diff
fetch
format-patch
fsck-objects
gitk
init-db
log
prune
pull .
pull other
push
rebase
repack
reset
revert
show-branch
status
whatchanged
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: linux @ 2005-12-09 21:54 UTC (permalink / raw)
To: junkio; +Cc: git, linux
In-Reply-To: <7vzmna2ig2.fsf@assigned-by-dhcp.cox.net>
> This primarily comes from the way git is architected. We have
> many commands that are not so interesting from the end-user
> perspective. If git were architected differently, many of them
> may not exist in executable command form, but would instead be
> library functions and listed in section 3git of the manual.
But you also have commands of interest or not to different classes
of users.
Some users want to track someone else's repository.
Others want to generate their repository from scratch.
Or maybe import some history from CVS.
Some users spend all day applying patches.
Some spend all day creating patches.
Some just want to retrieve the kernel and run "git bisect"
to help the kernel developers. They will neither generate
nor apply patches.
Some want access to a developer's git repository to test
bleeding-edge drivers.
Some folks want to set up remote access to a shared repository
within a development group.
Some folks want to set up an anonymous git server.
Et cetera. There are many different constituencies, who will
want access to a different subset of the commands.
> Exactly. The tutorial can also use a minor split. It starts
> out to give taste of internal workins of Porcelains, but ends up
> being a fuzzy mix of "user manual" and "hints to porcelain
> writers". We probably should have a separate "end user
> tutorial" --- the Alice-Bob scenario by Horst might be a good
> place to start.
That much, I definitely agree with. Mixing the two is confusing.
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Petr Baudis @ 2005-12-09 21:33 UTC (permalink / raw)
To: linux; +Cc: alan, git
In-Reply-To: <20051209140123.3234.qmail@science.horizon.com>
Dear diary, on Fri, Dec 09, 2005 at 03:01:23PM CET, I got a letter
where linux@horizon.com said that...
> >> Unfortunately, given the number of commands, you can't just document
> >> them well individually. Some overview of how they fit together into
> >> a system is required.
>
> > Hmm. Well, actually... what's the point? If I want to get a really quick
> > overview, I do
> >
> > whatis git
> >
> > and it will DTRT. But when do I need something more detailed but not yet
> > the manual page of the given command?
>
> "I want to do X and Y but not Z. What commands are worth knowing?"
Well, yes, that's the approach I advocate as well! It's precisely the
"task-based structured documentation" I talked about.
But the command listing is something different, actually the opposite:
"See, you have all those commands A, B, C. And this is what you can do
with them."
That's to say, the former requires a lot more effort and writing than
the latter and the latter has its uses as well, although I still think
the former is superior. :-)
> (BTW, don't you mean "whatis -w git\*"?)
$ whatis git
git (7) - the stupid content tracker
git-add (1) - Add files to the index file
git-am (1) - Apply a series of patches in a mailbox
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] use "git init-db" in tests
From: Junio C Hamano @ 2005-12-09 20:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512090259l5f06f6d6n5416e271af36d6a1@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> In my case it was the freshly build directory where a chmod 0666 * was
> done. This directory wont rebuild (the dates are correct), and the
> tests run, as if nothing happened.
I see. I appreciate your honesty ;-), it is a pilot error
alright, but surely it would be nicer if we catch it.
Although your proposed change makes it harder to implement
my desire to be able to run tests with installed binaries than
it already is, I'd take the patch for now. It would catch this
particular pilot error.
I however would think adding a dependency in t/Makefile to
make sure the top level is built before starting to run test a
overkill (I think I've seen some projects to do that), so I'd
not go there.
^ permalink raw reply
* Re: [RFC/PATCH] git-prune: never lose objects reachable from our refs.
From: Junio C Hamano @ 2005-12-09 20:38 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20051209193922.GA31228@ebar091.ebar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> On Thu, Dec 08, 2005 at 11:25:10PM -0800, Junio C Hamano wrote:
>> Explicit <head> arguments to git-prune replaces, instead of
>> extends, the list of heads used for reachability analysis by
>> fsck-objects. By giving a subset of heads by mistake, objects
>> reachable only from other heads can be removed, resulting in a
>> corrupted repository.
>>
>> This commit stops replacing the list of heads, and makes the
>> command line arguments to add to them instead for safety.
>
> Shouldn't the first sentence be "Explicit <head> arguments to git-prune
> extends, instead of replaces,...", that is, interchange the words
> extends and replaces? Did I miss something?
Sorry, what I meant was: "before this proposed change, it
replaces instead of extends --- which means DANGER. This
proposed change is to make things safer".
^ permalink raw reply
* Re: [RFC/PATCH] git-prune: never lose objects reachable from our refs.
From: Peter Eriksen @ 2005-12-09 19:39 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzja91gp.fsf_-_@assigned-by-dhcp.cox.net>
On Thu, Dec 08, 2005 at 11:25:10PM -0800, Junio C Hamano wrote:
> Explicit <head> arguments to git-prune replaces, instead of
> extends, the list of heads used for reachability analysis by
> fsck-objects. By giving a subset of heads by mistake, objects
> reachable only from other heads can be removed, resulting in a
> corrupted repository.
>
> This commit stops replacing the list of heads, and makes the
> command line arguments to add to them instead for safety.
Shouldn't the first sentence be "Explicit <head> arguments to git-prune
extends, instead of replaces,...", that is, interchange the words
extends and replaces? Did I miss something?
Peter
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Junio C Hamano @ 2005-12-09 19:12 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20051209140123.3234.qmail@science.horizon.com>
linux@horizon.com writes:
> "I want to do X and Y but not Z. What commands are worth knowing?"
>
> I have 106 git-* commands available to me (my document covers 105;
> I'll have to find the extra), and the biggest question I have is
> "how many of those man pages can I get away with NOT reading?"
This primarily comes from the way git is architected. We have
many commands that are not so interesting from the end-user
perspective. If git were architected differently, many of them
may not exist in executable command form, but would instead be
library functions and listed in section 3git of the manual.
> Heck, that categorized list is what I started out writing, and I happen
> to think it's the most important part of the whole document.
And I think I agree it but with a twist. The full listing for
Porcelain writers is mostly fine as is in git(7); maybe what you
wrote have clarification material, in which case I'd appreciate
a patch to Documentation/git.txt.
What we need is a separate list aimed for end users, and
somebody looking only at that list should be able to do
day-to-day work with only the commands listed there, and does
not even have to know something called rev-parse or merge-base
exist.
A good start for this list would be the list of selected
commands git.sh used to show (these days, git.c wrapper shows
everything that starts with "git", but the old one limited
itself to show only the ones that may be useful by the
end-user).
> The man page tells me HOW to execute a command. But before I'm ready for
> that level of detail, I need to figure out WHICH command to execute.
Exactly. The tutorial can also use a minor split. It starts
out to give taste of internal workins of Porcelains, but ends up
being a fuzzy mix of "user manual" and "hints to porcelain
writers". We probably should have a separate "end user
tutorial" --- the Alice-Bob scenario by Horst might be a good
place to start.
^ permalink raw reply
* Re: gitweb.cgi in C
From: Junio C Hamano @ 2005-12-09 17:59 UTC (permalink / raw)
To: Randal L. Schwartz, Mark Allen; +Cc: git
In-Reply-To: <86r78m8ea2.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Mark" == Mark Allen <mrallen1@yahoo.com> writes:
> Mark> I haven't looked at the libification work that Smurf is
> Mark> doing (haven't made time for it lately), but if it's not
> Mark> TOO python specific, maybe I can use it too.
> A "lite" version using Inline::C can be quickly constructed if
> only the API were all listed in one place, or a few easy to find places.
Guys, the "libificiation work" is more than that, and the more
important and bigger task is not the part you connect libgit to
your favorite P* languages, but first the part to reorganize
libgit to be usable in that form.
I've outlined what needs to be done a couple of months ago:
http://marc.theaimsgroup.com/?t=112687447700001
^ permalink raw reply
* JOB OPPORTUNITY.(VACANCIES).
From: Jonathan Yu Kim. @ 2005-12-10 9:14 UTC (permalink / raw)
To: linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4335 bytes --]
STARLINE CRUISES INTERNATIONAL SHIPPING CO. CANADA
IT IS A ROYAL WORLD CLASS LINNERS THAT SEATS OVER 2600 PASSENGERS.
The Grand Class features an unprecedented design with some of the most innovative amenities ever found on a cruise ship.
COMPANY'S OVERVIEW
From its modest beginnings in 1999 with a single ship cruising to Mexico, Starline has grown to become one of the premiere cruise lines in the world. Today, its fleet carries more than a million passengers each year to more worldwide destinations than any other major line.
The most recognized cruise line in the world was catapulted to stardom in 2000 when Pacific Starline was casted in a starring role on a new television show called The Love Boat. The weekly series, which introduced millions of viewers to the still-new concept of a sea-going vacation, was an instant hit and both the company name and its "SEAWITCH" logo have remained synonymous with cruising ever since. Starline' modern fleet has grown considerably in recent years to include Caribbean Starline (2004), ). Two additional new ships will join Starline' fleet by 2007, making it one of the most modern fleets on the high seas.
Personal Choice Cruising®
Building on past success, Starline is continually evolving to meet the needs of the today's vacationer. In the mid-2003 the company pioneered the concept of putting passengers in control of their own cruise experience with the introduction of its Sun-class ships. These revolutionary vessels gave passengers the freedom to choose from a wide range of flexible onboard facilities, amenities and services in order to create a personal vacation experience that takes the regimentation out of the cruise experience and suits each passenger's own needs and preferences.
REQUIREMENTS FOR QUALIFICATIONS.
ALL APPLICANTS MUST POCCESS AN O'LEVEL STATEMENT OF RESULT WITH A MINIMUM OF 2-3 CREDITS...ENGLISH LANGUAGE COMPULSORY.IF AVAILABLE, OTHER CERTIFICATES AS DIPLOMA AND DEGREE INCLUDING IT PROGRAM CERTIFICATES SHOULD ALSO BE SENT TO US VIA E MAIL AS A SCANNED ATTACHMENT.NOTE THAT RECRUITMENT OF WORKERS IS BASED ON THE PREMISE THAT ALL CERTIFICATES MUST BE ORIGINAL AND DUELY CERTIFIED.SHORTLISTED CABIN CREW MUST PRESENT SIX(6) COPIES OF PASSPORTS PHOTOS ALONGSIDE WITH A THREE(3) YEAR VALID INTERNATIONAL PASSPORTS AT THE IMMIGRATION CHECKPOINTS UPON ARRIVAL AT THE KUALA-LUMPUR INTERNATIONAL AIRPORT. EVERY SELECTED CABIN CREW MUST UNDER-GO TWO WEEKS TRAINING MALAYSIA BEFORE EMBARKING TO CANADA FOR HIS / HER SPECIFIC JOB. BEFORE ARRIVAL, A SCANNED COPY OF PAGES 2-5 OF SHORTLISTED CABIN,S INTERNATIONAL PASSPORTS AND BIRTH CERTIFICATES MUST BE SCANNED AND FORWARDED TO US VIA E MAIL ATTACHMENTS FOR AN IMMEDIATE CLEARANCE AT THE IMMIGRATION DEPARTMENT O!
F MALAYSIA. VISAS WOULD BE GIVEN ON ARRIVAL ACCORDINGLY.
A COPY OF A CLEAR MEDICAL REPORT IS EXPECTED OF EVERY SHORTLISTED CABIN CREW.
TERMS OF WORKING.
APPLICANTS SHOULD BE ABLE TO SIGN A MINIMUM OF ONE(1) YEAR CONTRACT WITH STARLINE CRUISE. CABINS CREW WILL ENJOY TWO(2) WEEKS LEAVE AFTER EVERY FIVE MONTHS OF WORK.
STARLINE CRUISES WILL TAKE CARE OF AIR TICKET, ACCOMODATIONS, FEEDING, INSURANCE AND MEDICAL EXPENCES OF EACH CABIN CREW ON BOARD.WORKERS ARE ENTITLED TO A MINIMUM OF $26000 USD SALARY DEPENDING ON QUALIFICATIONS AND NEGOTIATIONS OF THE DEPARTMENTAL HEADS.
VACANCIES:
IT Administrator, Account Executive, Admin Executive, Personal Assistant, Computer Engineer, Fork Lift Engineer, Communication Officer, Ship Cabin Crew Attendee, Computer Operators / Satellite Controllers.
N.B, INTERESTED APPLICANT IS ADVISED TO APPLY FOR A JOB WITH HIS / HER C.V AND AN APPLICATION LETTER. APPLICATION CLOSES ON 17TH DEC. 2005.
CONTACT ADDRESS:
HUMAN RESOURSES RECRUITMENT
STARlLINE CRUISE ADMINITRATIVE SDN PHD
CO.NO.388893-P STARLINE CRUISE TERMINAL,
AMPANG-INDA P.O.BOX 299-42229
PELABUHAN KIANG SELANGOR
MALAYSIA
TEL/ 0060132453070
HOT-LINE: 0060126195435
vacancies@starlinecruisescanada.com <mailto:vacancies@starlinecruisescanada.com>
info@starlinecruisescanada.com <mailto:info@starlinecruisescanada.com>
www.starlinecruises.com <http://www.starlinecruises.com/>
CONTACT PERSON:
JONATHAN YU KIM
0060162044019
starlinecruises@mail2marines.com <mailto:starlinecruises@mail2marines.com>
CHAIRMAN/CEO
ENGR.PETER CHONG LEE FAT
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Randy.Dunlap @ 2005-12-09 16:49 UTC (permalink / raw)
To: linux; +Cc: pasky, alan, git
In-Reply-To: <20051209140123.3234.qmail@science.horizon.com>
On Fri, 9 Dec 2005 linux@horizon.com wrote:
> >> Unfortunately, given the number of commands, you can't just document
> >> them well individually. Some overview of how they fit together into
> >> a system is required.
>
> > Hmm. Well, actually... what's the point? If I want to get a really quick
> > overview, I do
> >
> > whatis git
> >
> > and it will DTRT. But when do I need something more detailed but not yet
> > the manual page of the given command?
>
> "I want to do X and Y but not Z. What commands are worth knowing?"
I agree big time. Even for quilt (about 30 commands),
I wrote a summary (cheat sheet) of usage models:
a. making a new patch: use this series of commands
b. importing patches: use this other series of commands
c. other patch management commands
> I have 106 git-* commands available to me (my document covers 105;
> I'll have to find the extra), and the biggest question I have is
> "how many of those man pages can I get away with NOT reading?"
>
> Heck, that categorized list is what I started out writing, and I happen
> to think it's the most important part of the whole document.
>
> The man page tells me HOW to execute a command. But before I'm ready for
> that level of detail, I need to figure out WHICH command to execute.
> To be specific, I need to know the terrain just well enough so I can
> plan a route from where I am to where I want to be. Then I can look
> into the details of each step.
>
> But without that overview, my trip is going to take me into a lot of dead
> ends, because I'm executing commands that I think are getting me closer,
> but I have the wrong mental model of what "close" is.
--
~Randy
^ permalink raw reply
* Re: gitweb.cgi in C
From: Randal L. Schwartz @ 2005-12-09 15:45 UTC (permalink / raw)
To: Mark Allen; +Cc: junkio, git
In-Reply-To: <20051209152847.28358.qmail@web34310.mail.mud.yahoo.com>
>>>>> "Mark" == Mark Allen <mrallen1@yahoo.com> writes:
Mark> I started working on a GIT-XS project around GIT 0.9 timeframe, but the changes to APIs
Mark> and calls was still way too rapid, so I decided to back burner it.
Mark> I haven't looked at the libification work that Smurf is doing (haven't made time for it
Mark> lately), but if it's not TOO python specific, maybe I can use it too.
A "lite" version using Inline::C can be quickly constructed if
only the API were all listed in one place, or a few easy to find places.
I spent about ten minutes trying to find this information a few weeks
back, but apparently, that was about five minutes (or more) too short.
Any quick pointers on how -lgit is constructed?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: gitweb.cgi in C
From: Mark Allen @ 2005-12-09 15:28 UTC (permalink / raw)
To: merlyn, junkio; +Cc: git
Randal L. Schwartz wrote:
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Yes, that is exactly what I meant by what Smurf is working on --
Junio> libified git with Pyrex.
> Pyrex? not XS? I'd like to see Perl "use Git;". :)
I have a lot of interest in writing an XS interface for GIT but I've been waiting for 1.0
to officially release so I can be assured of a somewhat stable interface target.
I started working on a GIT-XS project around GIT 0.9 timeframe, but the changes to APIs
and calls was still way too rapid, so I decided to back burner it.
I haven't looked at the libification work that Smurf is doing (haven't made time for it
lately), but if it's not TOO python specific, maybe I can use it too.
Cheers,
--Mark
^ permalink raw reply
* Re: [ANNOUNCE] gitkdiff 0.1
From: Tejun Heo @ 2005-12-09 14:55 UTC (permalink / raw)
To: skimo; +Cc: Horst Kronstorfer, git
In-Reply-To: <20051209125627.GT30765MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege wrote:
> On Fri, Dec 09, 2005 at 10:45:33AM +0000, Horst Kronstorfer wrote:
>
>>Tejun Heo <htejun <at> gmail.com> writes:
>>
>>
>>> http://home-tj.org/gitui/files/gitui-200504281405.tar.gz
>>
>>link is dead. any alternatives available?
>>
>
> Probably not what you meant, but I think dirdiff does something similar.
> Some changes again Paul's version are available from
>
> http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary
>
http://home-tj.org/wiki/index.php/Mtkdiff
--
tejun
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: linux @ 2005-12-09 14:01 UTC (permalink / raw)
To: linux, pasky; +Cc: alan, git
In-Reply-To: <20051209094328.GT22159@pasky.or.cz>
> BTW, such a "wide" reply is a bit hard to handle - it might be perhaps
> more practical to make separate replies at least to the mails whose
> contents does not overlap. Also, people would not get Cc's of subthreads
> they are not involved with.
Sorry... it was one edit session while I made all the corrections,
and it was just more natural...
>> Unfortunately, given the number of commands, you can't just document
>> them well individually. Some overview of how they fit together into
>> a system is required.
> Hmm. Well, actually... what's the point? If I want to get a really quick
> overview, I do
>
> whatis git
>
> and it will DTRT. But when do I need something more detailed but not yet
> the manual page of the given command?
"I want to do X and Y but not Z. What commands are worth knowing?"
I have 106 git-* commands available to me (my document covers 105;
I'll have to find the extra), and the biggest question I have is
"how many of those man pages can I get away with NOT reading?"
Heck, that categorized list is what I started out writing, and I happen
to think it's the most important part of the whole document.
The man page tells me HOW to execute a command. But before I'm ready for
that level of detail, I need to figure out WHICH command to execute.
To be specific, I need to know the terrain just well enough so I can
plan a route from where I am to where I want to be. Then I can look
into the details of each step.
But without that overview, my trip is going to take me into a lot of dead
ends, because I'm executing commands that I think are getting me closer,
but I have the wrong mental model of what "close" is.
Or perhaps I found one command that sort-of does what I want an
missed the one that works better.
(BTW, don't you mean "whatis -w git\*"?)
^ permalink raw reply
* Re: [ANNOUNCE] gitkdiff 0.1
From: Sven Verdoolaege @ 2005-12-09 12:56 UTC (permalink / raw)
To: Horst Kronstorfer; +Cc: git
In-Reply-To: <loom.20051209T114016-464@post.gmane.org>
On Fri, Dec 09, 2005 at 10:45:33AM +0000, Horst Kronstorfer wrote:
> Tejun Heo <htejun <at> gmail.com> writes:
>
> > http://home-tj.org/gitui/files/gitui-200504281405.tar.gz
>
> link is dead. any alternatives available?
>
Probably not what you meant, but I think dirdiff does something similar.
Some changes again Paul's version are available from
http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary
skimo
^ permalink raw reply
* Re: [ANNOUNCE] gitkdiff 0.1
From: Horst Kronstorfer @ 2005-12-09 10:45 UTC (permalink / raw)
To: git
In-Reply-To: <4270711F.7020501@gmail.com>
Tejun Heo <htejun <at> gmail.com> writes:
> http://home-tj.org/gitui/files/gitui-200504281405.tar.gz
link is dead. any alternatives available?
-h
^ permalink raw reply
* Re: [PATCH] use "git init-db" in tests
From: Alex Riesen @ 2005-12-09 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkyu7l05.fsf@assigned-by-dhcp.cox.net>
On 12/9/05, Junio C Hamano <junkio@cox.net> wrote:
> > An accident? Like a filesystem not supporting executable permission?
> > What is the reason to report success from the test run in that conditions?
>
> Let's be reasonable. I was hoping to hear from you a real-world
> breakage case that I overlooked due to my lack of access to
> platforms you may have access to. I am not interested in a
> theoretical failure case discussion very much. If your
> filesystem does not support executables, why do you expect
> things to run from the freshly built directory to begin with?
In my case it was the freshly build directory where a chmod 0666 * was
done. This directory wont rebuild (the dates are correct), and the
tests run, as if nothing happened.
I actually noticed only after a half an hour, that I wasn't running
the executables I expected.
> Linkage error of git-init-db (or git wrapper) may leave the file
> created but leave that in unexecutable form, which could be a
> valid concern, but that would signal an error to the make during
> the build stage, and "test" target depends on "all" target.
>
> And please do not start arguing that you can cd to 't' directory
> after such a build failure and manually say "make". You can do
> that without even running make at the top level and cause the
> same failure. I consider both of them pilot errors.
Yes, but they are not obvious. It is also not obvious what to do,
because everything seams alright.
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Petr Baudis @ 2005-12-09 9:43 UTC (permalink / raw)
To: linux; +Cc: alan, git
In-Reply-To: <20051209054304.3908.qmail@science.horizon.com>
BTW, such a "wide" reply is a bit hard to handle - it might be perhaps
more practical to make separate replies at least to the mails whose
contents does not overlap. Also, people would not get Cc's of subthreads
they are not involved with.
Dear diary, on Fri, Dec 09, 2005 at 06:43:04AM CET, I got a letter
where linux@horizon.com said that...
> Finally, pasky@suse.de wrote:
> > That said, the "git for the confused" contains a lot of nice points, but
> > I don't think it's a good approach to just have extra document for
> > clarifying this stuff. It would be much better if the stock
> > documentation itself would not be confusing in the first place. Same
> > goes for the "commands overview" (BOUND to get out-of-date over time
> > since it's detached from the normal per-command documentation; we have
> > troubles huge enough to keep usage strings in sync, let alone the
> > manpages).
>
> I don't think it's the ideal solution either, but the idea of trying to
> supplant Linus' tutorial is a bit alarming given my current still-novice
> state. I've been dabbling with git for a few weeks; many of the people
> on this list have been using git in earnest for most of its life.
Now that's precisely what's most precious on you :-) - you have a fresh
perspective (and you don't seem to appear as a bad writer, at least to
me), actually much more important that technical correctness especially
for non-reference documentation like this; we'll catch possible
inaccuracies while reviewing, that's the least thing.
> Unfortunately, given the number of commands, you can't just document
> them well individually. Some overview of how they fit together into
> a system is required.
Hmm. Well, actually... what's the point? If I want to get a really quick
overview, I do
whatis git
and it will DTRT. But when do I need something more detailed but not yet
the manual page of the given command?
Now, having a task-based structured documentation (also called "user
manual" ;-) is an entirely different story and yes, that would be
extremely useful.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] use "git init-db" in tests
From: Petr Baudis @ 2005-12-09 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vvexy4ppw.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Dec 09, 2005 at 09:52:27AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Junio C Hamano <junkio@cox.net> writes:
>
> > Linkage error of git-init-db (or git wrapper) may leave the file
> > created but leave that in unexecutable form, which could be a
> > valid concern, but that would signal an error to the make during
> > the build stage, and "test" target depends on "all" target.
>
> BTW, I sometimes wished if it were easier to disable that "test:
> all" dependency and run tests without building things first,
> i.e. deliberately using the already installed binaries, so that
> I can make sure that updated or new tests reproduce and catch
> problems with the existing code first and then make sure the
> binaries built from the updated sources fix the problem.
>
> Of course that is a very specialized application so a makefile
> variable "make NO_BUILD_BEFORE_TEST=YesPlease test" would not
> make much sense, but I could have done something like this:
I think having "test-standalone" or "test-nobuild" or whatever rule and
test: all test-nobuild
test-nobuild:
...
would be much more elegant.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] use "git init-db" in tests
From: Junio C Hamano @ 2005-12-09 8:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <7vlkyu7l05.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linkage error of git-init-db (or git wrapper) may leave the file
> created but leave that in unexecutable form, which could be a
> valid concern, but that would signal an error to the make during
> the build stage, and "test" target depends on "all" target.
BTW, I sometimes wished if it were easier to disable that "test:
all" dependency and run tests without building things first,
i.e. deliberately using the already installed binaries, so that
I can make sure that updated or new tests reproduce and catch
problems with the existing code first and then make sure the
binaries built from the updated sources fix the problem.
Of course that is a very specialized application so a makefile
variable "make NO_BUILD_BEFORE_TEST=YesPlease test" would not
make much sense, but I could have done something like this:
---
diff --git a/Makefile b/Makefile
index 01b6643..8dd7be7 100644
--- a/Makefile
+++ b/Makefile
@@ -439,7 +439,13 @@ doc:
### Testing rules
-test: all
+ifdef NO_BUILD_BEFORE_TEST
+test_depends =
+else
+test_depends = all
+endif
+
+test: $(test_depends)
$(MAKE) -C t/ all
test-date$X: test-date.c date.o ctype.o
^ permalink raw reply related
* Re: [PATCH] use "git init-db" in tests
From: Junio C Hamano @ 2005-12-09 8:06 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512082336i674932bapd631d559e80cad79@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> An accident? Like a filesystem not supporting executable permission?
> What is the reason to report success from the test run in that conditions?
Let's be reasonable. I was hoping to hear from you a real-world
breakage case that I overlooked due to my lack of access to
platforms you may have access to. I am not interested in a
theoretical failure case discussion very much. If your
filesystem does not support executables, why do you expect
things to run from the freshly built directory to begin with?
Linkage error of git-init-db (or git wrapper) may leave the file
created but leave that in unexecutable form, which could be a
valid concern, but that would signal an error to the make during
the build stage, and "test" target depends on "all" target.
And please do not start arguing that you can cd to 't' directory
after such a build failure and manually say "make". You can do
that without even running make at the top level and cause the
same failure. I consider both of them pilot errors.
^ permalink raw reply
* Re: [PATCH] use "git init-db" in tests
From: Alex Riesen @ 2005-12-09 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jafcmev.fsf@assigned-by-dhcp.cox.net>
On 12/8/05, Junio C Hamano <junkio@cox.net> wrote:
> > You do miss something. glibc will happily continue lookup if
> > git-init-db in the top of the build directory is not executable, and
> > it will take the next one it finds (and people _will_ have git-init-db
> > in PATH).
>
> And the reason git-init-db we just built is not executable
> is...?
An accident? Like a filesystem not supporting executable permission?
What is the reason to report success from the test run in that conditions?
^ permalink raw reply
* Re: gitweb.cgi in C
From: Junio C Hamano @ 2005-12-09 7:33 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86irtyank4.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> Yes, that is exactly what I meant by what Smurf is working on --
> Junio> libified git with Pyrex.
>
> Pyrex? not XS? I'd like to see Perl "use Git;". :)
OK, for the record I should mention that I first suggested using
Swig, to be neutral across perl/python/tcl. BTW, this list is
merely alphabetical not suggesting the order of my preference
;-).
^ 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