* Re: New to Git / Questions about single user / multiple projects
From: Jakub Narebski @ 2009-08-19 7:59 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <a2db4dd50908181852s1e2c64fen8b883faf76b3136d@mail.gmail.com>
"Rob (gmail)" <robvanb@gmail.com> writes:
> I'm new to git and have some (I think) basic questions that I have
> not been able to find answers to in the documentation. It's very
> possible that these are the result of my lack in understanding git /
> version control, so feel free to point me to documentation that
> might contain the answers.
Documentation you might want to read:
* "Git User's Manual", distributed with Git (installed at least on
Linux at $sharedir/doc/git-$version/user-manual.html), also at
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
* "The Git Community Book", available at
http://book.git-scm.com/
* "Pro Git. Professional version control", available at
http://progit.org/book/
> Q1:
> Can I create a single repository (project?) for all my code, knowing
> that there are multiple small, unrelated projects. Or should I create
> a new repository for each project ?
You should create a new repository for each project. In git each
commit is about state of whole repository.
If you have single unrelated files, you might want to consider using
Zit tool (see http://git.or.cz/gitwiki/InterfacesFrontendsAndTools for
details), but beware that it is in early stages of development.
(Although if you choose one big repository, you can split it later
with some effort using git-filter-branch (or git-split somewhere in
mailing list archives) if you didn't publish your repositories).
> Q2:
> After initalizing my repository, and comitting the 1st batch of code:
> When further working on the code, will the command "git add ." add all
> changed and new files ? Or do I specifically need to list the new
> files ?
"git add ." would add _all_ new not ignored files, and would stage all
changed files. But you would have to be sure that all files you don't
want to be comitted, like generated files (*.o, *.log,...) and backup
files of your editor (*~ or *.bak), are ignored using .gitignore
(usually for generated files) and .git/info/excludes or
core.excludesFile (usually for specific patterns like backup files).
> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
> if from the root of the project ?
Most git commands take subdirectory they are in into consideration
when acting. "git add <filename>" in subdirectory works as expected.
Note that some commands need to have '.' as filename / pattern to be
limited to current subdirectory / act on current directory.
> --
> When in trouble or in doubt, run in circles, scream and shout
:-)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Simple commit mechanism for non-technical users
From: Jakub Narebski @ 2009-08-19 8:10 UTC (permalink / raw)
To: D Sundstrom; +Cc: git
In-Reply-To: <ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com>
D Sundstrom <sunds@peapod.net> writes:
> I use git to manage all project artifacts, including documentation,
> proposals, presentations, and so on.
>
> However, I have a hard time convincing non-technical staff to learn
> enough about git or to take the time to go through the effort of
> committing changes to a repository. So the steady stream of email
> attachments with "Acme Specification v3" or "final final spemco
> proprosal" continues.
>
> I'd hoped there was a simple web interface that would allow a user to
> upload and commit a file to a repository, but I've had no luck finding
> one. (I've used cgit for browsing, but it is read-only).
Some of git web interfaces or git hosting software offer editing via
web interface. Neither gitweb nor cgit offers this; it is available
AFAIK in GitHub (but it is not open source, and server version GitHub:FI
isn't cheap).
You can use some wiki (there are some wikis with git backend,
e.g. ikiwiki, see http://git.or.cz/gitwiki/InterfacesFrontendsAndTools)
or CMS like Drupal instead. Note that wikis usually work in
lock-edit-unlock mode (no merging changes), and have per page (per file)
versioning.
Alternate solution would be to use one of GUIs for Git, like
e.g. git-gui or QGit, or filemanager integration / shell extension
like (for MS Windows) TortoiseGit or Git Extensions.
> Is anyone aware of a simple way I can have my non-technical users
> manage their documents against a git repository? Ideally this would
> involve no installation of software on their machine (unless it were
> compelling, for example, the Finder plugin for SVN on the mac was a
> great tool for these users; or at least those on a mac...)
What operating system? What do you use currently?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* ls-files -t broken? Or do I just not understand it?
From: Björn Steinbrink @ 2009-08-19 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
ls-files -t seems to always show status H, even if the file was modified
or deleted, and thus gets shown by -m and -d respectively.
doener@atjola:git (master) $ git status
# On branch master
nothing to commit (working directory clean)
doener@atjola:git (master) $ rm git.c
doener@atjola:git (master) $ echo 123 > Makefile
doener@atjola:git (master) $ git ls-files -m
Makefile
git.c
doener@atjola:git (master) $ git ls-files -d
git.c
doener@atjola:git (master) $ git ls-files -t Makefile git.c
H Makefile
H git.c
doener@atjola:git (master) $ git add -u Makefile git.c
doener@atjola:git (master) $ git ls-files -m
doener@atjola:git (master) $ git ls-files -d
doener@atjola:git (master) $ git ls-files -t Makefile git.c
H Makefile
doener@atjola:git (master) $
I would have expected the first "ls-files -t" to say:
C Makefile
K git.c
Is that a bug, or am I just misunderstanding what -t is supposed to do?
Björn
^ permalink raw reply
* Re: Simple commit mechanism for non-technical users
From: Matthieu Moy @ 2009-08-19 8:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: D Sundstrom, git
In-Reply-To: <alpine.DEB.1.00.0908190940430.5594@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Then you have a bunch of people who do not want to care about learning
> proper version control.
OTOH, my experience with non-technical people and revision control is:
they send you an email with the file attached, saying they promise
they will learn the tool one day, but not right now because they don't
have time, and then you have to find out how to merge and commit
yourself.
And unfortunately (also from my experience), this is not limited to
non-technical people ...
For this category of people, a simple web-based commit tool will not
teach them anything (which is bad), but at least reduces the work of
the technical guys (which is somehow good).
--
Matthieu
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nguyen Thai Ngoc Duy @ 2009-08-19 8:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Jakub Narebski, Tomasz Kontusz, git
In-Reply-To: <alpine.DEB.1.00.0908190921360.5594@intel-tinevez-2-302>
On Wed, Aug 19, 2009 at 2:35 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> But here comes an idea: together with Nguy要's sparse series, it is
FWIW, you can write "Nguyen" instead. It might save you one copy/paste
(I take it you don't have a Vietnamese IM ;-)
> conceivable that we support a shallow & narrow clone via the upload-pack
> protocol (also making mithro happy). The problem with narrow clones was
> not the pack generation side, that is done by a rev-list that can be
> limited to certain paths. The problem was that we end up with missing
> tree objects. However, if we can make a sparse checkout, we can avoid
> the problem.
But then git-fsck, git-archive... will die?
--
Duy
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-19 8:29 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Erik Faye-Lund, Johan 't Hart, Junio C Hamano, msysgit, git,
lznuaa, bonzini
In-Reply-To: <4A8BA9EC.9000006@storm-olsen.com>
Hi,
On Wed, 19 Aug 2009, Marius Storm-Olsen wrote:
> The full IDE support is secondary, first because you *can* use the IDE
> already, and second because it'll be harder to whip something up which
> guarantees that the vcproj support stays in-sync at all times and won't
> lag behind.
I think the point of Frank's patches is to make Visual Studio users
comfortable with Git. You cannot ask those to use a build process or an
IDE they are not used to.
> Of course, if someone has a huge itch to restructure the current
> Makefile; factoring out the files into a file which can simply be
> included in the current Makefile, and easily parsed by a script, or
> included by CMake, then that can be done in parallel and possible added
> to git mainline before the MSVC support patches from Frank.
I still think it would be possible to use a combination of a
Makefile rule and GNU make features to spit out a list of targets and
their dependet .h and .c files.
Ciao,
Dscho
^ permalink raw reply
* Re: ls-files -t broken? Or do I just not understand it?
From: Matthieu Moy @ 2009-08-19 8:54 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, git
In-Reply-To: <20090819082423.GA18860@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Hi,
>
> ls-files -t seems to always show status H, even if the file was modified
> or deleted, and thus gets shown by -m and -d respectively.
That's not exactly "always", but I don't know whether it's the desired
behavior:
/tmp/git$ git st
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: modified
# deleted: removed
#
no changes added to commit (use "git add" and/or "git commit -a")
/tmp/git$ git ls-files -t
H modified
H removed
H unmodified
/tmp/git$ git ls-files -t -m
C modified
C removed
/tmp/git$ git ls-files -t -d
R removed
$ git ls-files -t -d -m
C modified
R removed
C removed
So, you get the C and R flags only when you request explicitely -m and
-d.
I'd say this is a bug, and anyway a testcase should be added to
explicitly state what the behavior should be.
--
Matthieu
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Thomas Berg @ 2009-08-19 8:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marius Storm-Olsen, Erik Faye-Lund, Johan 't Hart,
Junio C Hamano, msysgit, git, lznuaa, bonzini
In-Reply-To: <alpine.DEB.1.00.0908190951020.5594@intel-tinevez-2-302>
Hi,
On Wed, Aug 19, 2009 at 10:29 AM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 19 Aug 2009, Marius Storm-Olsen wrote:
>
>> The full IDE support is secondary, first because you *can* use the IDE
>> already, and second because it'll be harder to whip something up which
>> guarantees that the vcproj support stays in-sync at all times and won't
>> lag behind.
>
> I think the point of Frank's patches is to make Visual Studio users
> comfortable with Git. You cannot ask those to use a build process or an
> IDE they are not used to.
>
I don't know Frank's intentions behind adding the .vcproj files. Maybe
it was just easier for him to create them, rather than hacking the
Makefile?
As a Windows / Visual Studio user, I have to agree with Marius' points
here. Most importantly, get the git code itself to compile with Visual
Studio. Did anyone do any benchmarking yet? I wouldn't be surprised if
we got some speed improvements from this. Also, it will no longer
impossible to use the Visual Studio debugger.
Supporting the Visual Studio compiler in the Makefile seems like an
excellent and maintainable way of getting the build up and running.
I can't speek for all Visual Studio users, of course, but personally I
couldn't care less about the .vcproj files. I use other IDE's for
developing on Windows (qt-creator, eclipse-cdt), so for me .vcproj
files would be useless. The Makefile should work from any IDE. In my
experience, all of qt-creator, eclipse _and_ Visual Studio support
running any make-like program, and parse the compiler errors correctly
without using sed or other kinds of magic.
>
> I still think it would be possible to use a combination of a
> Makefile rule and GNU make features to spit out a list of targets and
> their dependet .h and .c files.
I wouldn't mind if someone was willing to add and maintain this, of
course, but at least for me it wouldn't be particularely useful.
Cheers,
Thomas Berg
^ permalink raw reply
* Re: ls-files -t broken? Or do I just not understand it?
From: Nguyen Thai Ngoc Duy @ 2009-08-19 9:04 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Björn Steinbrink, Junio C Hamano, git
In-Reply-To: <vpqljlguqtn.fsf@bauges.imag.fr>
On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy<Matthieu.Moy@imag.fr> wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
>> Hi,
>>
>> ls-files -t seems to always show status H, even if the file was modified
>> or deleted, and thus gets shown by -m and -d respectively.
>
> That's not exactly "always", but I don't know whether it's the desired
> behavior:
>
> /tmp/git$ git st
> # On branch master
> # Changed but not updated:
> # (use "git add/rm <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: modified
> # deleted: removed
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> /tmp/git$ git ls-files -t
> H modified
> H removed
> H unmodified
> /tmp/git$ git ls-files -t -m
> C modified
> C removed
> /tmp/git$ git ls-files -t -d
> R removed
> $ git ls-files -t -d -m
> C modified
> R removed
> C removed
>
> So, you get the C and R flags only when you request explicitely -m and
> -d.
Let's see how it goes without "-t":
pclouds@dektop /tmp/i $ git ls-files
modified
removed
unmodified
pclouds@dektop /tmp/i $ git ls-files -m
modified
removed
pclouds@dektop /tmp/i $ git ls-files -d
removed
pclouds@dektop /tmp/i $ git ls-files -d -m
modified
removed
removed
I'd say it's expected behavior.
--
Duy
^ permalink raw reply
* Re: ls-files -t broken? Or do I just not understand it?
From: Björn Steinbrink @ 2009-08-19 9:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Matthieu Moy, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0908190204h31bc839ai39972a251040d449@mail.gmail.com>
On 2009.08.19 16:04:20 +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy<Matthieu.Moy@imag.fr> wrote:
> > Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> >
> >> Hi,
> >>
> >> ls-files -t seems to always show status H, even if the file was modified
> >> or deleted, and thus gets shown by -m and -d respectively.
> >
> > That's not exactly "always", but I don't know whether it's the desired
> > behavior:
> >
> > /tmp/git$ git st
> > # On branch master
> > # Changed but not updated:
> > # (use "git add/rm <file>..." to update what will be committed)
> > # (use "git checkout -- <file>..." to discard changes in working directory)
> > #
> > # modified: modified
> > # deleted: removed
> > #
> > no changes added to commit (use "git add" and/or "git commit -a")
> > /tmp/git$ git ls-files -t
> > H modified
> > H removed
> > H unmodified
> > /tmp/git$ git ls-files -t -m
> > C modified
> > C removed
> > /tmp/git$ git ls-files -t -d
> > R removed
> > $ git ls-files -t -d -m
> > C modified
> > R removed
> > C removed
> >
> > So, you get the C and R flags only when you request explicitely -m and
> > -d.
>
> Let's see how it goes without "-t":
>
> pclouds@dektop /tmp/i $ git ls-files
> modified
> removed
> unmodified
> pclouds@dektop /tmp/i $ git ls-files -m
> modified
> removed
> pclouds@dektop /tmp/i $ git ls-files -d
> removed
> pclouds@dektop /tmp/i $ git ls-files -d -m
> modified
> removed
> removed
>
> I'd say it's expected behavior.
OK, so -t without _more_ than one of -c, -d, -m, -o, -u, -k simply
doesn't make much sense, right?
Björn
^ permalink raw reply
* Re: ls-files -t broken? Or do I just not understand it?
From: Nguyen Thai Ngoc Duy @ 2009-08-19 9:18 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Matthieu Moy, Junio C Hamano, git
In-Reply-To: <20090819091445.GB18860@atjola.homenet>
2009/8/19 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.08.19 16:04:20 +0700, Nguyen Thai Ngoc Duy wrote:
>> On Wed, Aug 19, 2009 at 3:54 PM, Matthieu Moy<Matthieu.Moy@imag.fr> wrote:
>> > Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>> >
>> >> Hi,
>> >>
>> >> ls-files -t seems to always show status H, even if the file was modified
>> >> or deleted, and thus gets shown by -m and -d respectively.
>> >
>> > That's not exactly "always", but I don't know whether it's the desired
>> > behavior:
>> >
>> > /tmp/git$ git st
>> > # On branch master
>> > # Changed but not updated:
>> > # (use "git add/rm <file>..." to update what will be committed)
>> > # (use "git checkout -- <file>..." to discard changes in working directory)
>> > #
>> > # modified: modified
>> > # deleted: removed
>> > #
>> > no changes added to commit (use "git add" and/or "git commit -a")
>> > /tmp/git$ git ls-files -t
>> > H modified
>> > H removed
>> > H unmodified
>> > /tmp/git$ git ls-files -t -m
>> > C modified
>> > C removed
>> > /tmp/git$ git ls-files -t -d
>> > R removed
>> > $ git ls-files -t -d -m
>> > C modified
>> > R removed
>> > C removed
>> >
>> > So, you get the C and R flags only when you request explicitely -m and
>> > -d.
>>
>> Let's see how it goes without "-t":
>>
>> pclouds@dektop /tmp/i $ git ls-files
>> modified
>> removed
>> unmodified
>> pclouds@dektop /tmp/i $ git ls-files -m
>> modified
>> removed
>> pclouds@dektop /tmp/i $ git ls-files -d
>> removed
>> pclouds@dektop /tmp/i $ git ls-files -d -m
>> modified
>> removed
>> removed
>>
>> I'd say it's expected behavior.
>
> OK, so -t without _more_ than one of -c, -d, -m, -o, -u, -k simply
> doesn't make much sense, right?
It shows you whether it's a normal entry (marked as "H") or unmerged
entry ("M") as far as I can tell. Junio may give more detail
explanation about this command.
--
Duy
^ permalink raw reply
* Re: [PATCH v5 0/6] {checkout,reset,stash} --patch
From: Thomas Rast @ 2009-08-19 9:40 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Sverre Rabbelier, Nanako Shiraishi,
Nicolas Sebrecht, Pierre Habouzit
In-Reply-To: <20090818164826.GA27377@coredump.intra.peff.net>
Jeff King wrote:
>
> I took a look at this today.
Heh, now *my* procrastination is paying off :-)
> Hmm. I was about to write "so we need some clever way of integrating the
> interactive hunk selection with a 3-way merge". But I just had a
> thought: we should do it in the reverse order. We do the three-way merge
> into a temporary index, and then ask the user to apply the result of
> _that_ tree into the working tree. Or maybe I am missing something else
> obvious and you can enlighten me.
I think that is the correct way to go about it from the user's POV.
He would be confused if the patch applied to WT/index were different
(because of a later merge) from the hunks he chose in the -p loop.
However, there's the issue of merge conflicts. Some options I can
think of are
1) refuse to work in the face of merge problems
2) stash requires a clean WT, so we can move the user's index out of
the way and use temporary index + WT to let the user resolve the
conflicts
3) require both clean WT and index so we can simply use the repo to
resolve
(The first one isn't quite as restrictive as it sounds; the user can
always apply on top of a clean HEAD, fix conflicts and re-stash, thus
doing a "stash rebase".)
> 1. For --index mode, it actually invokes add--interactive twice. It
> would be nice to do both passes at the same time, but I don't think
> it is possible with the current add--interactive infrastructure.
Note that the 'git stash -p' in next always stashes the index whole,
so the "easy" way might simply be to also unstash the index whole (if
requested).
The changes will usually still be available in the worktree
application, because the 3-way merge is between base and HEAD on one
side and base and worktree-stash on the other side.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Continue git clone after interruption
From: Johannes Schindelin @ 2009-08-19 9:52 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Nicolas Pitre, Jakub Narebski, Tomasz Kontusz, git
In-Reply-To: <fcaeb9bf0908190125u3e1bcaaap27e72a5784f4f9db@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1065 bytes --]
Hi,
On Wed, 19 Aug 2009, Nguyen Thai Ngoc Duy wrote:
> On Wed, Aug 19, 2009 at 2:35 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > But here comes an idea: together with Nguy要's sparse series, it is
>
> FWIW, you can write "Nguyen" instead. It might save you one copy/paste
> (I take it you don't have a Vietnamese IM ;-)
FWIW I originally wrote Nguyễn (not that Chinese(?) character)... I look
it up everytime I want to write your name by searching my address book for
"pclouds". ;-)
> > conceivable that we support a shallow & narrow clone via the
> > upload-pack protocol (also making mithro happy). The problem with
> > narrow clones was not the pack generation side, that is done by a
> > rev-list that can be limited to certain paths. The problem was that
> > we end up with missing tree objects. However, if we can make a sparse
> > checkout, we can avoid the problem.
>
> But then git-fsck, git-archive... will die?
Oh, but they should be made aware of the narrow clone, just like for
shallow clones.
Ciao,
Dscho
^ permalink raw reply
* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-19 9:53 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Nicolas Pitre, Tomasz Kontusz, git
In-Reply-To: <2e24e5b90908182142n16201ed4ua41408878664e353@mail.gmail.com>
On Wed, Aug 19, 2009, Sitaram Chamarty wrote:
> On Wed, Aug 19, 2009 at 12:15 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> > There is another way which we can go to implement resumable clone.
> > Let's git first try to clone whole repository (single pack; BTW what
> > happens if this pack is larger than file size limit for given
> > filesystem?). If it fails, client ask first for first half of of
> > repository (half as in bisect, but it is server that has to calculate
> > it). If it downloads, it will ask server for the rest of repository.
> > If it fails, it would reduce size in half again, and ask about 1/4 of
> > repository in packfile first.
>
> How about an extension where the user can *ask* for a clone of a
> particular HEAD to be sent to him as a git bundle? Or particular
> revisions (say once a week) were kept as a single file git-bundle,
> made available over HTTP -- easily restartable with byte-range -- and
> anyone who has bandwidth problems first gets that, then changes the
> origin remote URL and does a "pull" to get uptodate?
>
> I've done this manually a few times when sneakernet bandwidth was
> better than the normal kind, heh, but it seems to me the lowest impact
> solution.
>
> Yes you'd need some extra space on the server, but you keep only one
> bundle, and maybe replace it every week by cron. Should work fine
> right now, as is, with a wee bit of manual work by the user, and a
> quick cron entry on the server
This is a good idea, i think, and it can be implemented with various
amount of effort and changes to git, and various amount of seamless
integration.
1. Simplest solution: social (homepage). Not integrated at all.
On projects homepage, the one where there is described where project
repository is and how to get it, you add a link to most recent bundle
(perhaps in addition to most recent snapshot). This bundle would be
served as a static file via HTTP (and perhaps also FTP) by (any) web
server that supports resuming (range requests). Or you can make
server generate bundles on demand, only when they are first requested.
Most recent might mean latest tagged release, or it might mean daily
snapshot^W bundle.
This solution could be integrated into gitweb, either by generic
'latest bundle' link in project's README.html (or in site's
GITWEB_HOMETEXT, default indextext.html), or by having gitweb
generate those links (and perhaps bundles as well) by itself.
2. Seamless solution: 'bundle' or 'bundles' capability. Requires
changes to both server and client.
If server supports (advertises) 'bundle' capability, it can serve
list of bundles (as HTTP / FTP / rsync URLs) either at client request,
or after (or before) list of refs if client requests 'bundle'
capability.
If client has support for 'bundles' capability, it terminates
connection to sshd or git-daemon, and does ordinary resumable HTTP
fetch using libcurl. After bundle is downloaded fully, it clones
from bundle, and does git-fetch with the same server as before,
which would then have less to transfer. Client has also to handle
situation where bundle download is interrupted, and do not do cleanup,
allowing for "git clone --continue".
3. Seamless solution: GitTorrent or its simplification: git mirror-sync.
I think that GitTorrent (see http://git.or.cz/gitwiki/SoC2009Ideas)
or even its simplification git-mirror-sync would include restartable
cloning. It is even among its intended features. Also this would
help to download faster via mirrors which can have faster and better
network connection.
But this would be most work.
You can implement solution 1. even now...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/3] stash: reject stash name starting with a dash.
From: Jeff King @ 2009-08-19 9:57 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <vpq8whg1ebi.fsf@bauges.imag.fr>
On Wed, Aug 19, 2009 at 08:57:05AM +0200, Matthieu Moy wrote:
> >> +test_expect_success 'stash --invalid-option' '
> >> + echo bar5 > file &&
> >> + echo bar6 > file2 &&
> >> + git add file2 &&
> >> + ! git stash --invalid-option &&
> >> + test bar5,bar6 = $(cat file),$(cat file2) &&
> >> + git stash -- -message-starting-with-dash &&
> >> + test bar,bar2 = $(cat file),$(cat file2)
> >> +'
> >
> > Should this actually be "git stash save --invalid-option", since it is
> > really testing the actual save option parsing, and not the behavior to
> > automatically push options to "git stash save"?
>
> It could be, but the most annoying DWIM would be the "implicit save"
> case, so that's the one I'm testing. One could test both, but that'd
> probably be a bit overkill.
But if your proposal to accept any "-*' is not accepted, then it is not
testing your added code at all, is it? Even without the rest of the
patch, the test would pass.
-Peff
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-19 9:58 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <4A8AEAF5.6070205@gmail.com>
Hi,
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> Johannes Schindelin said the following on 18.08.2009 16:11:
>
> > On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> >
> > > diff --git a/Makefile b/Makefile
> > > +ifneq (,$(findstring Microsoft Visual Studio, $(INCLUDE)))
> ...
> > > +else
> > > ifneq (,$(findstring MINGW,$(uname_S)))
> > > pathsep = ;
> > > NO_PREAD = YesPlease
> >
> > This means that gcc is never used when Visual C++ is available? Hmm.
>
> Yes it does :)
As you know, I do not own a Windows computer. On the Windows computer I
am allowed to use sometimes to test Git and my day-time project, the
Express edition was installed, but it was never registered, so it is not
usable, and I would not want to use it anyway.
So this change would break my setup.
> I was actually going to replace it with a USE_MSVC variable check
> instead though, so you'd rather do 'make USE_MSVC=1'
That's much nicer, especially since you can put that into config.mak.
> > > diff --git a/compat/msvc.h b/compat/msvc.h
> > > index 6071565..a9d5f7f 100644
> > > --- a/compat/msvc.h
> > > +++ b/compat/msvc.h
> > > @@ -10,50 +10,120 @@
> > >
> > > /*Configuration*/
> > >
> > > +#ifndef NO_PREAD
> > > #define NO_PREAD
> > > +#endif
> >
> > Why? You now have the stuff in two places. If you want to keep them
> > in compat/msvc.h to be able to generate .vcproj files, I'd rather not
> > have them duplicated in the Makefile.
>
> The changes to the msvc.h where added just keep Frank's vcproj project
> working. I would have just nuked all that stuff in the msvc.h since the
> Makefile would just provide it for me anyways..
So maybe you and Frank (and Pau) hash out what you want?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v5 0/6] {checkout,reset,stash} --patch
From: Jeff King @ 2009-08-19 10:11 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, git, Sverre Rabbelier, Nanako Shiraishi,
Nicolas Sebrecht, Pierre Habouzit
In-Reply-To: <200908191140.22235.trast@student.ethz.ch>
On Wed, Aug 19, 2009 at 11:40:20AM +0200, Thomas Rast wrote:
> > I took a look at this today.
> Heh, now *my* procrastination is paying off :-)
Curses, I fell into your trap!
> I think that is the correct way to go about it from the user's POV.
> He would be confused if the patch applied to WT/index were different
> (because of a later merge) from the hunks he chose in the -p loop.
>
> However, there's the issue of merge conflicts. Some options I can
> think of are
>
> 1) refuse to work in the face of merge problems
I had assumed we would do (1), just to keep things simple. Otherwise
stash becomes a multi-invocation command (with a --continue feature),
which really has a lot of complexity and corner cases.
> 2) stash requires a clean WT, so we can move the user's index out of
> the way and use temporary index + WT to let the user resolve the
> conflicts
>
> 3) require both clean WT and index so we can simply use the repo to
> resolve
Actually, we currently require that the index and WT match, so
these two are equivalent. But I think they add a lot of complexity
because of the continuation.
> (The first one isn't quite as restrictive as it sounds; the user can
> always apply on top of a clean HEAD, fix conflicts and re-stash, thus
> doing a "stash rebase".)
Which is really a nice way of dodging the continuation bullet, since the
results after each step are well-defined in terms of currently existing
steps. That is, the user could "git stash apply" and never invoke "git
stash apply -p" if munging the conflicts led to the result they wanted.
OTOH, it may have been simpler for them to edit the stash beforehand to
avoid the conflicts.
Hmm. Maybe we are really talking about two different commands:
1. edit the hunks that will be applied to the working tree from the
stash (apply -p)
2. edit the _stash itself_, taking or leaving hunks to create a new
stash
What was in my patch was basically (2), but then always followed by
applying. By splitting them, you can use whichever makes sense for your
situation.
> > 1. For --index mode, it actually invokes add--interactive twice. It
> > would be nice to do both passes at the same time, but I don't think
> > it is possible with the current add--interactive infrastructure.
>
> Note that the 'git stash -p' in next always stashes the index whole,
> so the "easy" way might simply be to also unstash the index whole (if
> requested).
That might be worthwhile. It is less flexible, but I really wonder if
people actually keep stash randomly different changes in their index and
worktree and want to pick through them individually. I guess we could
also add a --patch-index for people who really wanted it.
-Peff
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Schindelin @ 2009-08-19 10:15 UTC (permalink / raw)
To: Frank Li; +Cc: Marius Storm-Olsen, Reece Dunn, git, msysgit
In-Reply-To: <1976ea660908180911m7469ac20w48a28b90262d25f6@mail.gmail.com>
On Wed, 19 Aug 2009, Frank Li wrote:
> > Okay, I will wait for Frank's updates (just fetched tgit.git and it still
> > contains the old branch), merge the early part and add the compiler flags.
> >
> Today, I just update 5 patch according review feedback.
> Do I need send it again?
>
> I have push my change to tgit
> git://repo.or.cz/tgit.git
> branch vcpatch2
>
> How do I know if patch has been applied main line?
I applied them to 4msysgit.git's devel. Note that I had a strange merge
conflict in pager.c: you replaced and #ifndef __MINGW32__ with an #ifndef
WIN32, but I don't have that #ifndef at all.
Ciao,
Dscho
^ permalink raw reply
* Re: Simple commit mechanism for non-technical users
From: Jeff King @ 2009-08-19 10:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: D Sundstrom, git
In-Reply-To: <alpine.DEB.1.00.0908190940430.5594@intel-tinevez-2-302>
On Wed, Aug 19, 2009 at 09:49:50AM +0200, Johannes Schindelin wrote:
> Then you have a bunch of people who do not want to care about learning
> proper version control.
>
> This is what I would do: write a very simple .cgi (I'd use Perl for that),
> which has a file upload button, takes the name as commit message (or maybe
> adds a field where you can type in a commit message, but that might be
> asking your bunch of Aunt Tillies too much), strips the "v3"-like suffixes
> ($name =~ s/[-_ ]*v\d+(\.[A-Za-z0-9]{1,5})$/$1/;), set author and
> committer information according to IP (and refuse if the IP is not in the
> internal mapping) and commit.
>
> The whole script would probably not be larger than 50 lines, and require
> Git to be installed on the server.
>
> The bigger problem is that your Aunt Tillies most likely would not love
> gitweb, so you need a fancier interface.
Actually, I think there is a technical problem here. You get Aunt
Tillie's v3, but you don't necessarily know what it is based on. So if
some other Aunt Tillie has submitted a v3 in the meantime, what do you
do with her file? Commit on top? Try to guess where her v2 was, branch
from there, and merge?
If you commit on top, then you are potentially erasing the other
person's work. If you do a merge, you are likely to get conflicts
(especially because Aunt Tillie likes to use horrible binary formats)
that _somebody_ will have to resolve.
I guess you can throw each Tillie on their own branch and then let
somebody clueful do the merging, but then you do not really have people
working together.
I think this is a fundamental issue. Most version control systems (and
especially distributed ones) are about doing concurrent work and
merging, and merging requires a bit of a clue. The Aunt Tillies of the
world really need a locking system to manage concurrency.
-Peff
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Sixt @ 2009-08-19 10:55 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Frank Li, Marius Storm-Olsen, Reece Dunn, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908191158310.5594@intel-tinevez-2-302>
Johannes Schindelin schrieb:
> On Wed, 19 Aug 2009, Frank Li wrote:
>> I have push my change to tgit
>> git://repo.or.cz/tgit.git
>> branch vcpatch2
>>
>> How do I know if patch has been applied main line?
>
> I applied them to 4msysgit.git's devel. Note that I had a strange merge
> conflict in pager.c: you replaced and #ifndef __MINGW32__ with an #ifndef
> WIN32, but I don't have that #ifndef at all.
4msysgit has my "Windows: Better support PAGER settings with spaces in the
path", which removes the #ifndefs, Frank's version doesn't have it.
Therefore, you should not rebase Frank's patches on top of 4msysgit's
master or devel before they are merged into git.git.
-- Hannes
^ permalink raw reply
* Re: [msysGit] Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-19 10:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marius Storm-Olsen, Erik Faye-Lund, Johan 't Hart,
Junio C Hamano, msysgit, git, lznuaa, bonzini
In-Reply-To: <alpine.DEB.1.00.0908190951020.5594@intel-tinevez-2-302>
Johannes Schindelin said the following on 19.08.2009 10:29:
> Hi,
>
> On Wed, 19 Aug 2009, Marius Storm-Olsen wrote:
>
>> The full IDE support is secondary, first because you *can* use the IDE
>> already, and second because it'll be harder to whip something up which
>> guarantees that the vcproj support stays in-sync at all times and won't
>> lag behind.
>
> I think the point of Frank's patches is to make Visual Studio users
> comfortable with Git. You cannot ask those to use a build process or an
> IDE they are not used to.
>
>> Of course, if someone has a huge itch to restructure the current
>> Makefile; factoring out the files into a file which can simply be
>> included in the current Makefile, and easily parsed by a script, or
>> included by CMake, then that can be done in parallel and possible added
>> to git mainline before the MSVC support patches from Frank.
>
> I still think it would be possible to use a combination of a
> Makefile rule and GNU make features to spit out a list of targets and
> their dependet .h and .c files.
Ok, but you would still have to rely on GNU Make in this setup, and it
would have to generate the common_cmds.h before you can even compile
with the MSVC IDE.
--
.marius
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Rob (gmail) @ 2009-08-19 11:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ab1wnsie.fsf@localhost.localdomain>
Thanks all for all the answers :)
One last question based on the multiple projects issue:
Is there a command that lists all your projects ?
My initial thought is that there probably isn't, as there is no
relation between the project except the userID ?
Thanks again,
Rob.
On Wed, Aug 19, 2009 at 3:59 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> "Rob (gmail)" <robvanb@gmail.com> writes:
>
>> I'm new to git and have some (I think) basic questions that I have
>> not been able to find answers to in the documentation. It's very
>> possible that these are the result of my lack in understanding git /
>> version control, so feel free to point me to documentation that
>> might contain the answers.
>
> Documentation you might want to read:
>
> * "Git User's Manual", distributed with Git (installed at least on
> Linux at $sharedir/doc/git-$version/user-manual.html), also at
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
>
> * "The Git Community Book", available at
> http://book.git-scm.com/
>
> * "Pro Git. Professional version control", available at
> http://progit.org/book/
>
>> Q1:
>> Can I create a single repository (project?) for all my code, knowing
>> that there are multiple small, unrelated projects. Or should I create
>> a new repository for each project ?
>
> You should create a new repository for each project. In git each
> commit is about state of whole repository.
>
>
> If you have single unrelated files, you might want to consider using
> Zit tool (see http://git.or.cz/gitwiki/InterfacesFrontendsAndTools for
> details), but beware that it is in early stages of development.
>
> (Although if you choose one big repository, you can split it later
> with some effort using git-filter-branch (or git-split somewhere in
> mailing list archives) if you didn't publish your repositories).
>
>> Q2:
>> After initalizing my repository, and comitting the 1st batch of code:
>> When further working on the code, will the command "git add ." add all
>> changed and new files ? Or do I specifically need to list the new
>> files ?
>
> "git add ." would add _all_ new not ignored files, and would stage all
> changed files. But you would have to be sure that all files you don't
> want to be comitted, like generated files (*.o, *.log,...) and backup
> files of your editor (*~ or *.bak), are ignored using .gitignore
> (usually for generated files) and .git/info/excludes or
> core.excludesFile (usually for specific patterns like backup files).
>
>> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
>> if from the root of the project ?
>
> Most git commands take subdirectory they are in into consideration
> when acting. "git add <filename>" in subdirectory works as expected.
>
> Note that some commands need to have '.' as filename / pattern to be
> limited to current subdirectory / act on current directory.
>
>> --
>> When in trouble or in doubt, run in circles, scream and shout
>
> :-)
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
--
When in trouble or in doubt, run in circles, scream and shout
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Jakub Narebski @ 2009-08-19 12:18 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <a2db4dd50908190400x1cbb1506sa38c60e31587f49d@mail.gmail.com>
Please do not toppost, and when responding cull the quoted part,
so only those parts that are relevant to your reply are remaining.
On Wed, 19 Aug 2009, Rob wrote:
> Thanks all for all the answers :)
>
> One last question based on the multiple projects issue:
> Is there a command that lists all your projects ?
>
> My initial thought is that there probably isn't, as there is no
> relation between the project except the userID ?
No, there no git commands for listing all your projects. BTW. you can
use different identities for different projects by setting it
in .git/config, i.e. in per-repository configuration file.
Simple solution, which finds only non-bare repositories, and which
can find false positives:
$ find ~ -name ".git" -type d -print
More complicated solution, used by gitweb, requires Perl, not checked
that it works correctly, doesn't work with ancient repositories with
symlink HEAD.
$ perl -e '
use File::Find qw(find);
my @list = ();
find({follow_fast => 1, follow_skip => 2, dangling_symlinks => 0,
wanted => sub {
return if (m!^[/.]$!);
return unless (-d $_);
push @list, $_ if -e "$_/HEAD"
}});
print join("\n", @list)."\n";
'
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Rob (gmail) @ 2009-08-19 12:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200908191418.08838.jnareb@gmail.com>
On Wed, Aug 19, 2009 at 8:18 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> Please do not toppost, and when responding cull the quoted part,
> so only those parts that are relevant to your reply are remaining.
Sorry, n00b mistake.
> BTW. you can
> use different identities for different projects by setting it
> in .git/config, i.e. in per-repository configuration file.
That seems like the best solution.
How do I delete my initial repository that I created and obviously messed up ?
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Jeff King @ 2009-08-19 12:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Rob (gmail), git
In-Reply-To: <200908191418.08838.jnareb@gmail.com>
On Wed, Aug 19, 2009 at 02:18:07PM +0200, Jakub Narebski wrote:
> More complicated solution, used by gitweb, requires Perl, not checked
> that it works correctly, doesn't work with ancient repositories with
> symlink HEAD.
>
> $ perl -e '
> use File::Find qw(find);
> my @list = ();
> find({follow_fast => 1, follow_skip => 2, dangling_symlinks => 0,
> wanted => sub {
> return if (m!^[/.]$!);
> return unless (-d $_);
> push @list, $_ if -e "$_/HEAD"
> }});
> print join("\n", @list)."\n";
> '
That doesn't seem very accurate. It will find 'HEAD' in "logs/" of
repositories with reflogs enabled, and "refs/remotes/*/" of cloned
repositories, giving you a lot of false positives.
If you want accuracy, you can ask git rev-parse to verify whether a
directory is a git repo; it actually uses a few different heuristics to
check. For example:
find . -type d |
while read dir; do
if GIT_DIR=$dir git rev-parse --git-dir >/dev/null 2>&1; then
echo $dir
fi
done
but it is a bit slower, as you invoke rev-parse for every directory, and
it actually does some verification of the contents of HEAD (so it is
probably a bad idea for something like gitweb, which cares about
performance).
If you want to do a cheap and fast check, searching for 'HEAD', 'refs',
and 'objects' in the same directory is a reasonable heuristic.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox