* 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: 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: 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: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: [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: 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: 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: 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: 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
* 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: 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
* 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: Johannes Schindelin @ 2009-08-19 7:49 UTC (permalink / raw)
To: D Sundstrom; +Cc: git
In-Reply-To: <ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com>
Hi,
On Tue, 18 Aug 2009, D Sundstrom wrote:
> 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).
>
> 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...)
You contradict yourself here, the Finder plugin needs to be installed, and
SVN, too.
As for your problem: I think you need a specific solution. If I
understand you correctly, files which have the same name (but maybe a
suffix "v3" or similar before the extension), and they should be
committed to a Git repository.
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.
Ciao,
Dscho
^ permalink raw reply
* Re: Continue git clone after interruption
From: Johannes Schindelin @ 2009-08-19 7:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Tomasz Kontusz, git
In-Reply-To: <alpine.LFD.2.00.0908181936130.6044@xanadu.home>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1531 bytes --]
Hi,
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> On Wed, 19 Aug 2009, Johannes Schindelin wrote:
>
> > But seriously, I miss a very important idea in this discussion: we
> > control the Git source code. So we _can_ add a upload_pack feature
> > that a client can ask for after the first failed attempt.
>
> Indeed. So what do you think about my proposal? It was included in my
> first reply to this thread.
Did you not talk about an extension of the archive protocol? That's not
what I meant. The archive protocol can be disabled for completely
different reasons than to prevent restartable clones.
But you brought up an important point: shallow repositories.
Now, the problem, of course, is that if you cannot even get a single ref
(shallow'ed to depth 0 -- which reminds me: I think I promised to fix
that, but I did not do that yet) due to intermittent network failures, you
are borked, as you said.
But here comes an idea: together with Nguyễn's sparse series, it is
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.
Note: this is not well thought-through, but just a brainstorm-like answer
to your ideas.
Ciao,
Dscho "who should shut up now and get some work done instead ;-)"
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-19 7:29 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Erik Faye-Lund, Johan 't Hart, Junio C Hamano, msysgit, git,
lznuaa, bonzini
In-Reply-To: <alpine.DEB.1.00.0908190910270.5594@intel-tinevez-2-302>
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]
Johannes Schindelin said the following on 19.08.2009 09:16:
> On Wed, 19 Aug 2009, Erik Faye-Lund wrote:
>> On Wed, Aug 19, 2009 at 12:38 AM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>>>> Nope, you're still able to skip through the erros (with F4)
>>>> as ususal. I've been using a sed-script to translate
>>>> gcc-style errors to msvc-style errors for makefile projects
>>>> before with great success. In this case, the errors are
>>>> already in msvc-style, so that part should really not be any
>>>> issue.
>>> At this point you are just piling work-around on work-around.
>> At what point?
>
> At the point where you bolt on a sed script on top of a bolted-on
> build procedure.
>
> Using a Makefile from within Visual Studio is just not the intended
> way to do things, so you will hit the limitations sooner or later.
>
> For example when the sed script encounters a situation which was
> not anticipated by the script author.
>
> So I think if we support Microsoft Visual C++, it should be either
> through .vcproj files, or through a procedure that creates them.
IMO, and I'm primarily a Windows developer mind you and spend a lot of
time in Visual Studio, the primary is to support *compiling* git with
VC, which is easily done with a few changes to the current Makefile.
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.
If you want, you can even use Qt Creator's Makefile support on any
platform to build and debug git, and get tab completion, code
refactoring support, 'quick open' navigation etc. So, I still think
the primary focus should be to simply add the VC support in the
current setup, and ensure that the patch series is up to scratch; and
when that's all done, *then* add the effort of properly supporting the
various IDEs.
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.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-19 7:16 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Marius Storm-Olsen, Johan 't Hart, Junio C Hamano, msysgit,
git, lznuaa, bonzini
In-Reply-To: <40aa078e0908181548t5df05b1ct8013b99ea703ebba@mail.gmail.com>
Hi,
On Wed, 19 Aug 2009, Erik Faye-Lund wrote:
> On Wed, Aug 19, 2009 at 12:38 AM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> >> Nope, you're still able to skip through the erros (with F4) as ususal.
> >> I've been using a sed-script to translate gcc-style errors to msvc-style
> >> errors for makefile projects before with great success. In this case,
> >> the errors are already in msvc-style, so that part should really not be
> >> any issue.
> >
> > At this point you are just piling work-around on work-around.
>
> At what point?
At the point where you bolt on a sed script on top of a bolted-on build
procedure.
Using a Makefile from within Visual Studio is just not the intended way to
do things, so you will hit the limitations sooner or later.
For example when the sed script encounters a situation which was not
anticipated by the script author.
So I think if we support Microsoft Visual C++, it should be either through
.vcproj files, or through a procedure that creates them.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Matthieu Moy @ 2009-08-19 7:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0908190035140.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 18 Aug 2009, Matthieu Moy wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > But it is sloppy, in that it blindly accepts options that might be
>> > valid for several subcommands, not just "save".
>>
>> I wouldn't call that sloppy. 'save' is the default command, if you don't
>> provide any command, then 'save' will be used.
>
> 'save' might be the default command, but we don't trigger it with _any_
> crap, for a very good reason. Read the commit log for git-stash.sh to
> know why.
The good reason was people doing a typo when typing a command, like
'git stash aply' or so. And yes, I did find this annoying. The
question of someone omitting the subcommand is very different to me.
On can hardly type 'git stash -q' and claim he explicitely wanted to
run 'pop'.
Your proposal will almost certainly trigger complains from users:
git stash -k => works
git stash -k -q => doesn't work
git stash -k "name of stash" => doesn't work
git stash save -k "name of stash" => works
git stash -p => works with another patch merged in next
git stash -q => doesn't work
git stash --patch --no-keep-index => works
git stash --no-keep-index --patch => doesn't work
You'll have a hard time explaining that to bare mortals.
Look at what's the code's becomming:
+ 0,,|1,-k,|1,--keep-index,|1,-p,|1,--patch,|2,-p,--no-keep-index|2,--patch,--no-keep-index)
when the code starts having to enumerate so many possibilities instead
of having a simple logic, something's going wrong.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 3/3] stash: reject stash name starting with a dash.
From: Matthieu Moy @ 2009-08-19 6:57 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20090818233535.GB6304@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Aug 18, 2009 at 11:38:43PM +0200, Matthieu Moy wrote:
>
>> This avoids typos like 'git stash save --invalid-option', particularly
>> nasty since one can omit the 'save' subcommand. The syntax
>> 'git stash save -- "-name starting with dash" still allows such stash name.
>
> Aside from the documentation and usage lines, this one is actually
> independent of the other two, and I think makes sense regardless of what
> happens.
I also do (but I'm not sure this is important enough to be in maint,
especially since it'll introduce silly textual conflicts in docs when
merging).
>> +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.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] graph API: fix bug in graph_is_interesting()
From: Junio C Hamano @ 2009-08-19 6:25 UTC (permalink / raw)
To: Adam Simpkins; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <7vhbw41g3f.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Adam Simpkins <simpkins@facebook.com> writes:
>
>> -enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
>> +enum commit_action get_commit_action(struct rev_info *revs, struct commit *commit)
>> {
>> if (commit->object.flags & SHOWN)
>> return commit_ignore;
>> @@ -1692,12 +1692,21 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
>> if (!commit->parents || !commit->parents->next)
>> return commit_ignore;
>> }
>> - if (want_ancestry(revs) && rewrite_parents(revs, commit) < 0)
>> - return commit_error;
>> }
>> return commit_show;
>> }
>>
>> +enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
>> +{
>> + enum commit_action action = get_commit_action(revs, commit);
>> +
>> + if (action == commit_show && revs->prune && revs->dense && want_ancestry(revs)) {
>> + if (rewrite_parents(revs, commit) < 0)
>> + return commit_error;
>> + }
>> + return action;
>> +}
>
> When simplify_commit() logic (now called get_comit_action()) decides to
> show this commit because revs->show_all was specified, we did not rewrite
> its parents, but now we will?
That is, here is what I meant...
revision.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 15a2010..efa3b7c 100644
--- a/revision.c
+++ b/revision.c
@@ -1700,7 +1700,9 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
{
enum commit_action action = get_commit_action(revs, commit);
- if (action == commit_show && revs->prune && revs->dense && want_ancestry(revs)) {
+ if (action == commit_show &&
+ !revs->show_all &&
+ revs->prune && revs->dense && want_ancestry(revs)) {
if (rewrite_parents(revs, commit) < 0)
return commit_error;
}
We may want to add some tests to demonstrate the breakage this fix
addresses.
^ permalink raw reply related
* Re: [PATCH] graph API: fix bug in graph_is_interesting()
From: Junio C Hamano @ 2009-08-19 6:18 UTC (permalink / raw)
To: Adam Simpkins; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20090819023433.GP8147@facebook.com>
Adam Simpkins <simpkins@facebook.com> writes:
> -enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
> +enum commit_action get_commit_action(struct rev_info *revs, struct commit *commit)
> {
> if (commit->object.flags & SHOWN)
> return commit_ignore;
> @@ -1692,12 +1692,21 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
> if (!commit->parents || !commit->parents->next)
> return commit_ignore;
> }
> - if (want_ancestry(revs) && rewrite_parents(revs, commit) < 0)
> - return commit_error;
> }
> return commit_show;
> }
>
> +enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
> +{
> + enum commit_action action = get_commit_action(revs, commit);
> +
> + if (action == commit_show && revs->prune && revs->dense && want_ancestry(revs)) {
> + if (rewrite_parents(revs, commit) < 0)
> + return commit_error;
> + }
> + return action;
> +}
When simplify_commit() logic (now called get_comit_action()) decides to
show this commit because revs->show_all was specified, we did not rewrite
its parents, but now we will?
^ permalink raw reply
* Re: Simple commit mechanism for non-technical users
From: Chris Packham @ 2009-08-19 6:09 UTC (permalink / raw)
To: D Sundstrom; +Cc: git
In-Reply-To: <ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com>
On Wed, Aug 19, 2009 at 4:05 AM, D Sundstrom<sunds@peapod.net> wrote:
> 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).
>
> 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...)
>
> -David
> --
Actually this is one situation that I'd say there are better solutions
than git _ducks_.
The solution I've been trying to push people toward at my day job is
using a wiki (we chose mediawiki but all the extra markup might still
scare non-techies). Wiki's are version controlled (in a simple,
centralized fashion) and allow editing from multiple authors and can
be updated quickly. The only client software you need is a web
browser. Plenty of open source projects use wikis for their living
specifications.
You may also want to look around for other content management systems
but the only one I've used kinda sucked. Not sure if there are any
good open source ones (but then again I haven't really looked).
If you still want to use git as your version control system for these
kinds of documents it shouldn't actually be too hard to implement and
simple uploader to complement a viewer like cgit or gitweb.
Unfortunately I don't know of any that exist but maybe someone else on
the list does.
^ permalink raw reply
* Re: Continue git clone after interruption
From: Sitaram Chamarty @ 2009-08-19 4:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nicolas Pitre, Tomasz Kontusz, git
In-Reply-To: <m3fxbpneqe.fsf@localhost.localdomain>
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
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Chris Packham @ 2009-08-19 4:14 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <eafc0afe0908181924x60e5dd23vd37711db880ead84@mail.gmail.com>
My $0.02
On Wed, Aug 19, 2009 at 1:52 PM, Rob (gmail)<robvanb@gmail.com> wrote:
> 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 ?
Thats entirely up to you. I prefer keeping lots of little repositories
for unrelated projects. That way I can use cool things like git
archive to generate tarballs if/when I need to. Although I do use the
single repository method sometimes when I'm feeling lazy. One thing
git has over some other VCSes is the ability to track changes past
renames. That way you can start off lazy and just have a fairly flat
code structure and then as you start to group code into logical sets
you can move them into directories without any danger of losing
history (one tip though, do the moving as a commit on its own this
makes the re-name detection work a lot better).
As Changsheng pointed out. You can also have the best of both worlds
and use git submodules to tie together multiple repositories. Although
I've always though of submodules as more of a build tool when you want
to track components of a larger system i.e. a linux distro might track
the kernel, kde, gnome ... and use a submodule setup to track known
stable points where those components work together.
>
> 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 ?
You can use 'git add -u' which adds any locally modified (but not
completely new) files to the index (its basically the first half of
'git commit -a'). For the new files either 'git add .' or list the
files.
> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
> if from the root of the project ?
Yes all the git commands work from subdirectories (well except
init/clone) . This is actually really useful if you want to get the
history of a component in a large code base without getting a lot of
irrelevant changes in other components.
^ permalink raw reply
* Re: [PATCH][resend 3] git-svn: Use GIT_SSH setting if SVN_SSH is not set
From: Eric Wong @ 2009-08-19 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Karthik R
In-Reply-To: <4A8B3F40.10803@fastmail.fm>
Karthik R <karthikr@fastmail.fm> wrote:
> If SVN_SSH is defined, it will be used. Else value in
> GIT_SSH is copied to SVN_SSH & then, only on Windows,
> the \s are escaped.
>
> On Windows, the shell-variables must be set as follows
> GIT_SSH="C:\Program Files\PuTTY\plink.exe"
> SVN_SSH="C:\\Program Files\\PuTTY\\plink.exe"
>
> See http://code.google.com/p/msysgit/issues/detail?id=305
>
> Signed-off-by: Karthik Rajagopalan <karthikr@fastmail.fm>
Thanks Karthik,
Acked and pushed out along with a few others I hadn't pushed
to git://yhbt.net/git-svn
Eric Wong (1):
svn: assume URLs from the command-line are URI-encoded
Karthik R (1):
git-svn: Use GIT_SSH setting if SVN_SSH is not set
Tuomas Suutari (1):
git-svn.txt: Fix location of parent argument
--
Eric Wong
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Daniel Barkalow @ 2009-08-19 4:00 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <a2db4dd50908181852s1e2c64fen8b883faf76b3136d@mail.gmail.com>
On Tue, 18 Aug 2009, Rob (gmail) wrote:
> 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.
>
> I'm doing ERP development for my job and various 'hobby' development
> in my spare time.
> I'd like to track/store/ version control the code that I write for
> both work and play.
> I am (currently) working by myself, no need to have multiple
> developers working of the same code.
>
> 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 ?
It's much easier to have a new repository for each project. There are two
possible ways to put multiple projects in a single repository: (1) you
could have each one in a subdirectory, which is bad because each commit
records the entire tree, so each project would have commits in its history
that are about other projects; (2) you could have separate branches for
each project; this is fine, but you only get one working directory per
repository, so it's awkward because you can only have one of your projects
checked out at a time.
On the other hand, it's pretty trivial to have lots of repositories, and
there isn't really any disadvantage to it. In fact, you may want to have
more repositories than projects at times, if you use the same project for
multiple purposes and want to extend it in different ways at the same
time.
> 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 ?
You can use "git add .", but be aware that this tends to pick up random
cruft you've left in the directory.
> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
> if from the root of the project ?
You can run almost every git command from subdirectories, and it does what
you'd expect with filenames when you're in a subdirectory. E.g., "git add
x" while in "a/b/" is like being in the project root and running "git add
a/b/x"
-Daniel
*This .sig left intentionally blank*
^ 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