* Re: [Announce] gitview-0.1
From: Junio C Hamano @ 2006-02-01 20:01 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Dave Jones, git, junkio
In-Reply-To: <cc723f590602010328w7b4a7befr40a76620e197d00c@mail.gmail.com>
Aneesh Kumar <aneesh.kumar@gmail.com> writes:
> for parent_id in parent_sha1 parent_sha2 parent_sha3 .......
> commit_diff = commit_diff + git diff tree -p parent_id commit_sha1
>
> is this the correct way ?
Are parent_sha$N true parents of commit_sha1? If you want to
get three independent diffs, "git diff-tree -m -p $commit_sha1"
would give that to you in one go.
^ permalink raw reply
* Re: [Announce] gitview-0.1
From: Linus Torvalds @ 2006-02-01 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aneesh Kumar, Dave Jones, git
In-Reply-To: <7v3bj2df1b.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Feb 2006, Junio C Hamano wrote:
>
> Are parent_sha$N true parents of commit_sha1? If you want to
> get three independent diffs, "git diff-tree -m -p $commit_sha1"
> would give that to you in one go.
Btw, I think we should change
git-diff-tree --stdin
to look at the rest of the line.
Right now it _only_ takes the commit from that line, along with possibly
the first parent if one exists (if one is not listed, the list of parents
will be correctly taken from the commit).
Which makes it mostly useless for merges with a dense history.
Especially with the new "-cc" flag, using it for merges really does make
a lot of sense, but it's not workable.
So right now, git-whatchanged does
git-rev-list | git-diff-tree --stdin <filelist>
which means that it handles merges in a pruned-down history wrong. Now,
that's ok, because it currently never prunes the history of git-rev-list
(it instead prunes purely in git-diff-tree). So it works right, and can
take the -cc flag because it always gets the parent information from the
commit.
HOWEVER, currently doing the pruning the other way around, ie
git-rev-list --parents <filelist> | git-diff-tree --stdin
does _not_ work right. It ignores anything but the first parent, because
"git-diff-tree --stdin" doesn't understand merges.
And doing the pruning the other way around would actually make sense
sometimes. Not for git-whatchanged (where doing the pruning in
git-diff-tree means that we don't have to parse the history ahead of time,
so we get immediate feedback), but in a git-annotate context you want to
do the pruning ahead-of-time. So git-diff-tree not supporting it is sad ;(
Linus
^ permalink raw reply
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-02-01 20:27 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0602011125370.5397@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 31 Jan 2006, Junio C Hamano wrote:
>
>> People who do not like this can set in their config file some
>> flag, say, 'core.index = understood', to get the current
>> behaviour.
>
> I'd avoid hidden config options that magically change behaviors and
> semantics like that as much as possible....
I agree; it was tongue-in-cheek sort of suggestion ;-)
> It is much more intuitive to expect that, if you specify path arguments
> to commit, then only those paths are considered, and even if you didn't
> do a git add on some of them. If nothing is specified then the current
> index (the default, including a-new-file) is considered.
Good thinking. I was not thinking about the case where you
explicitly list an untracked file to be added.
> - a non-merge commit without any argument would imply -a.
>
> - a non-merge commit with path arguments implies _only_ those paths,
> regardless if they were previously "git add"ed or not.
>
> - a non-merge commit with, say, --no-auto or --current-index or
> whatever would preserve the current behavior, with or without
> additional paths.
>
> - a merge commit ...
> - a merge commit ...
>
> This might look complicated when presented like that, but I think that
> the default behavior of each (non-merge vs merge) commit would more
> closely fit most people's expectations....
If I may correct what I said earlier, I now realize the
"automatic -a is dangerous" argument does not have anything to
do with merges. If the user usually works with a dirty working
tree, is aware of the index, and takes advantage of the index as
the staging area for the next commit, your --no-auto would be
needed to help her workflow. I in principle agree with the
first three items in the above summary, except that I think it
would make more sense to do that for all commits.
How about this:
- "git commit --also fileA..." means: update index at listed
paths (add/remove if necessary) and then commit the tree
described in index (the current behaviour with explicit paths).
- "git commit fileA..." means: create a temporary index from the
current HEAD commit (or empty index if there is none), update
it at listed paths (add/remove if necessary) and commit the
resulting tree. Also update the real index at the listed
paths (add/remove if necessary). In the original index file,
the paths listed must be either empty or match exactly the
HEAD commit -- otherwise we error out (Linus' suggestion).
- "git commit" means: update index with all local changes and
then commit the tree described in index (current "-a"
behaviour).
- In all cases, revert the index to the state before the
command is run if we end up not making the commit (e.g. index
unmerged, empty log message, pre-commit hook refusal).
Experienced git users would end up saying "--also" without
explicit paths to defeat the automatic -a behaviour all the
time, and while the flag --also makes perfect sense when used
with one or more paths, using it like this look awkward:
$ edit some-file
$ git update-index some-file
$ git commit --also
It's just a flag name so we could make --no-auto synonym to --also.
A minor twist of the above to make it friendlier to the current
git users is to do this:
- "git commit fileA...", "git commit -a", and "git commit" keep
the existing semantics.
- "git commit --only fileA..." does the new temporary index
thing.
This has an advantage that existing use is not affected, and
another advantage is that internally it is more consistent ("git
commit" is a natural extension of "git commit fileA..." with
zero path). But one possible downside is that you need to
explicitly say --only when you want cvs-like "commit".
Since we are discussing that the people find existing
interface to be unintuitive, being consistent with the current
usage may not count as a big advantage after all..
^ permalink raw reply
* Re: [PATCH] git-svnimport.perl: fix for 'arg list too long...'
From: Junio C Hamano @ 2006-02-01 20:27 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git, Matthias Urlichs
In-Reply-To: <20060201155331.GE18078@sashak.voltaire.com>
Sasha Khapyorsky <sashak@voltaire.com> writes:
> This fixes 'arg list too long..' problem with git-ls-files.
I wonder if feeding the list into a pipe to 'update-index --stdin'
would be an option.
BTW, please do not do this:
Mail-Followup-To: Junio C Hamano <junkio@cox.net>,
Matthias Urlichs <smurf@smurf.noris.de>, git@vger.kernel.org
It is simply rude.
* I and/or Smurf may be uninterested in hearing the whole
discussion thread started by you. We might well be, but that
is not something you shoudl decide upfront in your message.
* When a recipient of your message tries to "[R]eply" to *you*,
that Mail-Followup-To: would cause the MUA to address that
message to me and/or smurf by default, not to you. I had to
edit the resulting To: header by hand to address this
response to you. Why force extra work on others?
I know why you did it --- you subscribe to git list and
otherwise you would get two copies.
That is _not_ a good excuse. That is how mailing lists work;
either you filter the duplicates on your end, or you learn to
live with it. Please don't force extra work on others.
I think the only header mucking of this kind that is acceptable
is to remove yourself from CC: line when the mailing list you
subscribe to is already on the CC: line.
^ permalink raw reply
* Re: [PATCH] Shallow clone: low level machinery.
From: Junio C Hamano @ 2006-02-01 20:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602011528030.28923@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > Worse, you cannot pull from older servers into shallow repos.
>>
>> "have X" means different thing if you do not have matching
>> grafts information, so I suspect that is fundamentally
>> unsolvable.
>
> If the shallow-capable client could realize that the server is not
> shallow-capable *and* the local repo is shallow, and refuse to operate
> (unless called with "-f", in which case the result may or may not be a
> broken repo, which has to be fixed up manually by copying
> over ORIG_HEAD to HEAD).
"If ... refuse to operate" then? If "Then that is OK" is what
you meant to say I agree (I meant to code the client code that
way but I started only with the initial clone). I said
"fundamentally unsolvable" because I thought you wanted it to do
something sensible without refusing even in such a case.
> Of course, the client has to know that the local repo is shallow, which it
> must not determine by looking at the grafts file.
Sorry, I fail to understand this requirement. Why is it "it must not"?
> If you introduce a different "have X" -- like "have-no-parent X" -- and
> teach git-rev-list that "~A" means "traverse the tree of A, but not A's
> parents", you'd basically have everything you need, right?
If you have such a modified rev-list, yes. I was having doubts
about keeping an obvious correctness guarantee when doing such
"rev-list ~A".
> Yes, I agree. But again, the local repo has to know which grafts were
> introduced by making the repo shallow.
I am not sure I understand. grafts are grafts are grafts. If
the other side has grafts to connect otherwise unrelated commit
objects, I suspect the cloner needs to know about them, all of
them, in order to use the resulting clone. Also the upstream
side would need to know the altered world view the cloner has to
adjust the commit ancestry graph, at least during the cloning
and fetching, and I do not think it should be limited only to
cauterizign entries created by earlier shallow clone operations.
Manually created cauterizing entries should also count (for that
matter, grafts to stitch unrelated lines together), No?
^ permalink raw reply
* Re: [Announce] gitview-0.1
From: Junio C Hamano @ 2006-02-01 20:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Aneesh Kumar, Dave Jones, git
In-Reply-To: <Pine.LNX.4.64.0602011206040.21884@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, I think we should change
>
> git-diff-tree --stdin
>
> to look at the rest of the line.
Yes it is one of the "broken things I am aware of". It does not
even show --pretty for the same reason, and I was planning to do
a fake commit objects to handle them (taking the message from
commit, locally grafting the parents from the line to it).
^ permalink raw reply
* Re: How to use git for Linux kernel development ?
From: J. Bruce Fields @ 2006-02-01 20:38 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: git
In-Reply-To: <200602011238.44188.laurent.pinchart@tbox.biz>
On Wed, Feb 01, 2006 at 12:38:44PM +0100, Laurent Pinchart wrote:
> I have no idea how to layout my git repository to work on day-to-day
> development. I need to :
>
> - commit bug fixes, external patches and internal modifications to a branch
> (or possibly on separate branches depending on what I commit if needed). The
> work will be based on Linux kernel 2.6.15 but I'd like to stay up-to-date
> with the master repository as much as possible.
> - push bug fixes upstream by creating a patchset and submitting it by email.
> - pull changes from upstream and merge them in my various branches when the
> upstream versions become stable enough.
> - keep branches for all the versions shipped to the customers for bug fixes.
>
> I'm the only developer working on the Linux kernel in my company, but that
> might change in a few months, so other developers will need to use git as
> well.
>
> Is git able to accomodate my needs ?
Those certainly sound like the kinds of things it's meant for.
> I've been trying to setup a git repository with a few branches over
> the last two days, but I always had to throw everything away and start
> back from zero. I haven't been able to figure out which branches I
> should create and how I should use them.
Maybe you could be more specific about the problems you've had?
--b.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-02-01 20:48 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86bqxr8kms.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> *1* The reason he has unrelated changes while doing a merge is
> Junio> because he works on things himself (I am speculating about
> Junio> this),
>
> You need to speculate that Linus works on things himself? :)
Forgot a smiley ;-).
^ permalink raw reply
* Re: [Announce] gitview-0.1
From: Alex Riesen @ 2006-02-01 20:58 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: git
In-Reply-To: <cc723f590601312016vabba201ye6d3739b3927f1a@mail.gmail.com>
Aneesh Kumar, Wed, Feb 01, 2006 05:16:59 +0100:
>
> Gnome based git repository browser. The code is derived from bazaar-ng
> repository browser.
>
> To see how it looks
>
> http://www.flickr.com/photos/17388011@N00/92918446/
>
> I don't have a web location where i can host it so i am attaching it below.
> It would be great if we can get it added to git repository
>
> sample usage
> takes same argument as git rev-list
>
> gitview --since=2.week.ago
>
Doesn't really work here: no tree like on your screenshot, and a lot
of messages like this:
(gitview:14905): GLib-GObject-WARNING **: IA__g_object_set_property: object clas
s `PyGtkGenericCellRenderer' has no property named `out-lines'
(gitview:14905): GLib-GObject-WARNING **: IA__g_object_set_property: object clas
s `PyGtkGenericCellRenderer' has no property named `in-lines'
(gitview:14905): GLib-GObject-WARNING **: IA__g_object_set_property: object clas
s `PyGtkGenericCellRenderer' has no property named `node'
(gitview:14905): GLib-GObject-WARNING **: IA__g_object_set_property: object clas
s `PyGtkGenericCellRenderer' has no property named `out-lines'
(gitview:14905): GLib-GObject-WARNING **: IA__g_object_set_property: object clas
s `PyGtkGenericCellRenderer' has no property named `in-lines'
(gitview:14905): GLib-GObject-WARNING **: IA__g_object_set_property: object clas
s `PyGtkGenericCellRenderer' has no property named `node'
Traceback (most recent call last):
File "/home/raa/gitview", line 166, in on_render
ctx = window.cairo_create()
AttributeError: 'gtk.gdk.Window' object has no attribute 'cairo_create'
Gentoo, Python 2.4.2, pycairo 1.0.2.
^ permalink raw reply
* Re: [Announce] gitview-0.1
From: Fernando J. Pereda @ 2006-02-01 21:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: Aneesh Kumar, git
In-Reply-To: <20060201205805.GA6384@steel.home>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
On Wed, Feb 01, 2006 at 09:58:05PM +0100, Alex Riesen wrote:
| Gentoo, Python 2.4.2, pycairo 1.0.2.
Just upgrade to a newer pygtk and it'll work fine:
[ebuild R ] dev-python/pygtk-2.8.2 -doc +opengl 0 kB
I had the same problem until I installed the above version.
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Census] So who uses git?
From: Linus Torvalds @ 2006-02-01 21:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vhd7ibza2.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Feb 2006, Junio C Hamano wrote:
>
> How about this:
>
> - "git commit --also fileA..." means: update index at listed
> paths (add/remove if necessary) and then commit the tree
> described in index (the current behaviour with explicit paths).
I'd suggest "--incremental" instead of "--also".
> - "git commit fileA..." means: create a temporary index from the
> current HEAD commit (or empty index if there is none), update
> it at listed paths (add/remove if necessary) and commit the
> resulting tree. Also update the real index at the listed
> paths (add/remove if necessary). In the original index file,
> the paths listed must be either empty or match exactly the
> HEAD commit -- otherwise we error out (Linus' suggestion).
Yes.
> - "git commit" means: update index with all local changes and
> then commit the tree described in index (current "-a"
> behaviour).
No. Please no. "git commit" should continue to do what it does now.
Otherwise you can't do the two-stage thing in any sane way.
Requiring "--incremental"/"--also" is very confusing.
If somebody doesn't know about the index, he normally will never have
index changes _anyway_, except for the "git add" case. In which case "git
commit" does the right thing for him: it will either commit the added
files, or it will say "nothing to commit".
Linus
^ permalink raw reply
* Re: [Census] So who uses git?
From: linux @ 2006-02-01 21:27 UTC (permalink / raw)
To: linux, raa.lkml; +Cc: git, torvalds
In-Reply-To: <81b0412b0602010810m3577263csed57ba75e0d6bb64@mail.gmail.com>
> Inodes are either uselessor dangerous in cygwin (hash of an
> absolute pathname on FAT). They may not even change after rm+touch.
Yes, I just looked it up and found that out. I was hoping they used
first block number like many Linux FSes have tried, in which case it
would have worked, but if it's a hash of the path name, it's
guaranteed not to change.
And Linus' point is excellent, too: this feature is also useful
for automated systems (like git-applypatch) that can be assumed to
never forget to warn git ahead of time.
^ permalink raw reply
* [PATCH] git-svnimport: Allow direct access over https.
From: Jason Riedy @ 2006-02-01 21:31 UTC (permalink / raw)
To: git
I'm not sure what the benefits of "direct access" are,
but it works over https as well as http.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
71596fc3eb8d2ea25bd8fc99c03d2171d4136d88
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 6e3a44a..63339ef 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -141,7 +141,7 @@ if($opt_d or $opt_D) {
} else {
$svn_dir = "";
}
- if ($svn_url->scheme eq "http") {
+ if ($svn_url->scheme eq "http" || $svn_url->scheme eq "https") {
use LWP::UserAgent;
$lwp_ua = LWP::UserAgent->new(keep_alive => 1, requests_redirectable => []);
} else {
--
1.1.5.g4a2b
^ permalink raw reply related
* Re: [Census] So who uses git?
From: Nicolas Pitre @ 2006-02-01 21:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0602011307250.21884@g5.osdl.org>
On Wed, 1 Feb 2006, Linus Torvalds wrote:
>
>
> On Wed, 1 Feb 2006, Junio C Hamano wrote:
> >
> > How about this:
> >
> > - "git commit --also fileA..." means: update index at listed
> > paths (add/remove if necessary) and then commit the tree
> > described in index (the current behaviour with explicit paths).
>
> I'd suggest "--incremental" instead of "--also".
>
> > - "git commit fileA..." means: create a temporary index from the
> > current HEAD commit (or empty index if there is none), update
> > it at listed paths (add/remove if necessary) and commit the
> > resulting tree. Also update the real index at the listed
> > paths (add/remove if necessary). In the original index file,
> > the paths listed must be either empty or match exactly the
> > HEAD commit -- otherwise we error out (Linus' suggestion).
>
> Yes.
Agreed.
> > - "git commit" means: update index with all local changes and
> > then commit the tree described in index (current "-a"
> > behaviour).
>
> No. Please no. "git commit" should continue to do what it does now.
> Otherwise you can't do the two-stage thing in any sane way.
>
> Requiring "--incremental"/"--also" is very confusing.
>
> If somebody doesn't know about the index, he normally will never have
> index changes _anyway_, except for the "git add" case. In which case "git
> commit" does the right thing for him: it will either commit the added
> files, or it will say "nothing to commit".
Sensible. As long as "commit files..." actually commits _only_ those
files unless --index (or something) is specified to also explicitly
include the index changes.
What is really counter-intuitive is to have index changes merged by
default when a single file is specified as argument to commit.
Nicolas
^ permalink raw reply
* Re: How to use git for Linux kernel development ?
From: Junio C Hamano @ 2006-02-01 21:43 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: git
In-Reply-To: <200602011238.44188.laurent.pinchart@tbox.biz>
Laurent Pinchart <laurent.pinchart@tbox.biz> writes:
> ... I haven't been able to figure
> out which branches I should create and how I should use them.
Bruce already responded to this part in a more polite way, but
let me be more blunt. You need to figure out how your project
and workflow is to be organized first, and that needs your own
thinking. We could help, but you know your project better than
any of us. The organization of what git branches to use and how
would fall out as a natural consequence of your workflow.
> ... If really unable to use git, I'll go for SVN (or
> SourceSafe as that's what my company used until today, but I'd
> like to avoid it) even if I feel it will make keeping
> up-to-date with upstream more difficult.
And I suspect you would have the same workflow issues regardless
of the choice of any SCM (some SCM may _force_ particular
workflow on you though; which may be a good thing -- it reduces
confusion coming from having too many possibilities to choose
from).
For example, with my simplified world view, I would do something
like this:
master::
the tip of the latest of your product.
vanilla::
the tip of the Linus vanilla kernel. you do not
commit to it---you only update it via "git fetch".
kfix::
forked somewhere from refs/heads/vanilla, and may
occasionally be updated by merging from it, to
hold your own bugfixes meant for mainline.
maint/1.0, maint/1.1, maint/1.2,...::
forked somewhere from master when you do a release.
Your product specific work is done in master. In practice, you
probably would emply "topic branch" workflow to grow the master,
but that is covered pretty well by Tony Luck in one of our howto
documents, so I would not repeat it here. External patches you
pick up from elsewhere would go in the master as well.
When working on bugs present in the vanilla kernel, You checkout
kfix, work in there and commit fixes to this branch. It may be
a good idea to occasionally sync this branch with vanilla when
your changes conflict with upstream changes. This is the branch
you would publish to the outside world for consumption by the
kernel community (other branches probably need to be published
to satisfy your GPL obligations as well).
You would merge from kfix into master as needed.
When you release your version 1.0 product, you would tag
"master", and at the same time, branch "maint/1.0" from there.
Further post-release fixes you would commit to maint/1.0
branch. You might make further tags 1.0.1, 1.0.2 on this branch
as needed.
^ permalink raw reply
* Re: [PATCH] git-svnimport.perl: fix for 'arg list too long...'
From: Sasha Khapyorsky @ 2006-02-01 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthias Urlichs
In-Reply-To: <7v64nybz9m.fsf@assigned-by-dhcp.cox.net>
On 12:27 Wed 01 Feb , Junio C Hamano wrote:
> Sasha Khapyorsky <sashak@voltaire.com> writes:
>
> > This fixes 'arg list too long..' problem with git-ls-files.
>
> I wonder if feeding the list into a pipe to 'update-index --stdin'
> would be an option.
This can be option for git-update-index, but my problem was with
git-ls-files, git-update-index was ok (arg list processing were splitted
already).
>
> BTW, please do not do this:
>
> Mail-Followup-To: Junio C Hamano <junkio@cox.net>,
> Matthias Urlichs <smurf@smurf.noris.de>, git@vger.kernel.org
>
> It is simply rude.
OK, will not. Thanks for pointing.
Sasha.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-02-01 21:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.64.0602011307250.21884@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> - "git commit" means: update index with all local changes and
>> then commit the tree described in index (current "-a"
>> behaviour).
>
> No. Please no. "git commit" should continue to do what it does now.
> Otherwise you can't do the two-stage thing in any sane way.
> Requiring "--incremental"/"--also" is very confusing.
I myself did not like it but...
> If somebody doesn't know about the index, he normally will never have
> index changes _anyway_, except for the "git add" case. In which case "git
> commit" does the right thing for him: it will either commit the added
> files, or it will say "nothing to commit".
... the original complaint was that "git commit" without
explicit paths does not quack like "cvs/svn commit" -- commit
all my changes in the working tree.
And actually the one you are responding to was my cunning move
to pull this exact reaction from you: "No commit without
parameter should not imply -a". I prefer the "minor twist"
version in the same messge myself.
To recap:
- "git commit fileA..." means: update index at listed paths
(add/remove if necessary) and then commit the tree described
in index (the same as the current behaviour with explicit
paths).
- "git commit -a" means: update index with all local changes and
then commit the tree described in index (the same as the
current behaviour).
- "git commit" means: write out the current index and commit
(the same as the current behaviour).
- "git commit --only fileA..." means: create a temporary index
from the current HEAD commit (or empty index if there is
none), update it at listed paths (add/remove if necessary)
and commit the resulting tree. Also update the real index at
the listed paths (add/remove if necessary). In the original
index file, the paths listed must be either empty or match
exactly the HEAD commit -- otherwise we error out (Linus'
suggestion).
- In all cases, revert the index to the state before the
command is run if we end up not making the commit (e.g. index
unmerged, empty log message, pre-commit hook refusal). With
this, "git diff-files fileA" would show the differences as it
showed beforean aborted "git commit -a" or "git commit fileA"
and removes one common gripe.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Joel Becker @ 2006-02-01 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Linus Torvalds, git
In-Reply-To: <7vhd7ibza2.fsf@assigned-by-dhcp.cox.net>
On Wed, Feb 01, 2006 at 12:27:17PM -0800, Junio C Hamano wrote:
> - "git commit fileA..." means: create a temporary index from the
> current HEAD commit (or empty index if there is none), update
> it at listed paths (add/remove if necessary) and commit the
Please don't do the add/remove automatically. I know, it's
pretty convenient if I explicitly say "git commit filetoadd", but what
happens if I say "git commit libfoo/*"? I know that I want all my
changes in libfoo/ to be commited, ignoring my changes in libbar/. But
I forgot that I created libfoo/testfoo.c to debug my changes, and now
it's in the repository -- and I might not even notice it for weeks.
CVS and Subversion require an explicit "add" for this very
reason. Even then, almost everyone gets an "import" or two wrong,
pulling in a couple built files (eg, "configure") they didn't mean to
get.
I guess you could query the user. "I noticed that you specified
filetoadd, and you never said 'git add'. Do you want to add it now
[Y/n]?"
Joel
--
"When I am working on a problem I never think about beauty. I
only think about how to solve the problem. But when I have finished, if
the solution is not beautiful, I know it is wrong."
- Buckminster Fuller
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [Census] So who uses git?
From: Nicolas Pitre @ 2006-02-01 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v8xsu91vf.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Feb 2006, Junio C Hamano wrote:
> To recap:
>
> - "git commit fileA..." means: update index at listed paths
> (add/remove if necessary) and then commit the tree described
> in index (the same as the current behaviour with explicit
> paths).
No.
> - "git commit -a" means: update index with all local changes and
> then commit the tree described in index (the same as the
> current behaviour).
Sensible.
> - "git commit" means: write out the current index and commit
> (the same as the current behaviour).
Sensible.
> - "git commit --only fileA..." means: create a temporary index
> from the current HEAD commit (or empty index if there is
> none), update it at listed paths (add/remove if necessary)
> and commit the resulting tree. Also update the real index at
> the listed paths (add/remove if necessary). In the original
> index file, the paths listed must be either empty or match
> exactly the HEAD commit -- otherwise we error out (Linus'
> suggestion).
Actually, my opinion is that should be the behavior for your first item
above (when only filenames are specified). If you want to _also_
include the index like you describe in your first item then an
additional switch should be provided.
In other words, the --only should become --with-index with the behavior
swapped.
The fact is that when you simply specify a filename, you really expect
_only_ that filename will be affected and the rest be left alone.
That's the most probable expectation for any tool. If you want
_additional_ stuff to also be merged along with the files specified then
it is logical to have an additional argument in that case, not the other
way around.
Nicolas
^ permalink raw reply
* Re: [Census] So who uses git?
From: Linus Torvalds @ 2006-02-01 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7v8xsu91vf.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Feb 2006, Junio C Hamano wrote:
>
> ... the original complaint was that "git commit" without
> explicit paths does not quack like "cvs/svn commit" -- commit
> all my changes in the working tree.
Agreed. However, I think that one is pretty easy to explain, and
conceptually it's not a problem to just tell people to use the "-a" flag
if they want to get CVS/SVN semantics.
After all, "git commit" will actually make it pretty obvious in the commit
message status, _and_ if you haven't done any "git add" you'll get the
"nothing to commit" thing, so it's not like this is hard to explain.
The real _confusion_ I think came from the filename usage.
Linus
^ permalink raw reply
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-02-01 22:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git, Joel Becker
In-Reply-To: <Pine.LNX.4.64.0602011717010.5397@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> Actually, my opinion is that should be the behavior for your first item
> above (when only filenames are specified). If you want to _also_
> include the index like you describe in your first item then an
> additional switch should be provided.
OK, agreed. Sorry to be slow.
So, to recap:
git commit paths... (temporary index thing)
git commit --incremental paths... (same as current w/o --incremental)
git commit (same as current)
git commit -a (same as current)
And I agree with Joel that we should not automatically imply
"git add" with or without --incremental.
I do not particularly have much preference among --also,
--with-index, or --incremental, but:
- 'with-index' is precise but might be too technical;
- 'incremental' is not really incremental -- you can use it
only once.
Because you do not have to say "git commit --also" without paths
(which _is_ awkward) to get the traditional behaviour, maybe it
is a good name for that flag (it is also the shortest).
^ permalink raw reply
* Re: [PATCH] git-svnimport.perl: fix for 'arg list too long...'
From: Junio C Hamano @ 2006-02-01 22:50 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git, Matthias Urlichs
In-Reply-To: <20060201215454.GB31711@sashak.voltaire.com>
Sasha Khapyorsky <sashak@voltaire.com> writes:
> On 12:27 Wed 01 Feb , Junio C Hamano wrote:
>> Sasha Khapyorsky <sashak@voltaire.com> writes:
>>
>> > This fixes 'arg list too long..' problem with git-ls-files.
>>
>> I wonder if feeding the list into a pipe to 'update-index --stdin'
>> would be an option.
>
> This can be option for git-update-index, but my problem was with
> git-ls-files, git-update-index was ok (arg list processing were splitted
> already).
I was commenting on the "while (@o1)" loop that splices at 50
when the list has more than 55 items to feed update-index. You
could accumulate output from multiple invocations of ls-files
and feed everything to a single "update-index --stdin" after the
"while (@old)" loop is done. Batch of 50 vs a single batch may
not matter though [*1*].
But you are right; that git-ls-files can get too many arguments
unless you split like that.
A casual skimming over the rest of the code tells me that this
fixes the last instance of such a command invocation with too
many arguments. Good catch.
Smurf, I do not have problems with Sasha's patch. Are you OK
if I apply it?
-- >8 --
*1* I do not think this makes much of a difference but here is what
I mean.
diff --git a/git-svnimport.perl b/git-svnimport.perl
index b6799d8..d76a595 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -546,7 +546,8 @@ sub commit {
}
}
- while(@old) {
+ my @u = ();
+ while (@old) {
my @o1;
if(@old > 55) {
@o1 = splice(@old,0,50);
@@ -555,26 +556,19 @@ sub commit {
@old = ();
}
open my $F, "-|", "git-ls-files", "-z", @o1 or die $!;
- @o1 = ();
local $/ = "\0";
while(<$F>) {
chomp;
- push(@o1,$_);
+ push(@u,$_);
}
close($F);
-
- while(@o1) {
- my @o2;
- if(@o1 > 55) {
- @o2 = splice(@o1,0,50);
- } else {
- @o2 = @o1;
- @o1 = ();
- }
- system("git-update-index","--force-remove","--",@o2);
- die "Cannot remove files: $?\n" if $?;
- }
}
+ open my $F, "|-",
+ qw(git-update-index --force-remove -z --stdin)
+ or die $!;
+ print $F "$_\0" for @u;
+ close $F or die $!;
+
while(@new) {
my @n2;
if(@new > 12) {
^ permalink raw reply related
* Tracking and committing back to Subversion?
From: Sam Vilain @ 2006-02-01 22:51 UTC (permalink / raw)
To: Git Mailing List
Hi all,
Has anyone done any work on bidirectional access to SVN repositories?
ie, tracking and committing.
That would be porcelain that behaves like SVK (http://svk.elixus.org)
Ideally it would probably need to link against the Subversion RA (remote
access) library, neon.
I can see forsee two potential issues;
1. file properties - such as mime type, ignores and custom properties.
Linus, when I asked you about this in Dunedin, you mentioned that
there is a place at the end of the directory entry where this could
fit without breaking backwards compatibility. Perhaps this could
be an optional pointer to another directory node;
/
trunk/ # after all, we're tracking an SVN repo ;)
MyModule/
Makefile.PL
MyModule.pm
<prop-dir>/
svn:ignore
<prop-dir> is a directory object, with one file in this example;
called svn:ignore. The contents of this file would be something
like the .gitignore;
Makefile
Makefile.old
blib
...etc...
This configures the directory "/trunk/MyModule" to have a property
"svn:ignore", which makes SVN ignore those files.
2. "forensic" file movement history - as opposed to the uncached,
(and unversioned), automatic "analytical" file movement history.
It would be easy for a tool to provide 100% interface compatibility
with SVN client/SVK using properties, but properties that hang off
the head rather than the file itself (so that they don't stuff up
the ability to merge identical trees reached via independent
paths). SVN calls these "revision properties". If a good
convention is adopted for this, it could be used as a nice way to
supplement git's automatic analysis of the revision history.
So, then, git could support these three methods of finding
revision history;
1. automatic/analytical, as at present. Cachable information,
and such a cache would not form part of the revision history.
2. forensic, if using porcelain that supports it; this would
form part of the revision history, but be out of band to the
content.
3. (potentially) retrospective, for instance, somebody studying
an old code base and tracking history for some reason - or
even 'correcting' forensic revision history that is causing
their advanced patch calculus algorithm to trip up (should
someone be using git as a storage back-end for darcs, for
instance)
Ideally, it would be possible to distinguish between 2 and 3, of
course this would require two head identifiers; the content head,
and the revision history head.
This might seem like functionality not needed for merging kernel
trees ;) but I think it would add value to be able to make git truly
join the trump suit in the VCS deck (along with SVK, which can, for
instance, track Perforce and even git repositories).
Sam.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Daniel Barkalow @ 2006-02-01 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <7v8xsu91vf.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Feb 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > If somebody doesn't know about the index, he normally will never have
> > index changes _anyway_, except for the "git add" case. In which case "git
> > commit" does the right thing for him: it will either commit the added
> > files, or it will say "nothing to commit".
>
> ... the original complaint was that "git commit" without
> explicit paths does not quack like "cvs/svn commit" -- commit
> all my changes in the working tree.
Actually, the original complaint was about "git commit path ...", I
believe. That's the case where new users are finding that the behavior is
surprising, rather than just unfamiliar.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Question around git-shell usage in Everyday Git
From: Alan Chandler @ 2006-02-01 23:01 UTC (permalink / raw)
To: git
In the Repository Administrator section of the Everyday Git document it shows
how to allocate accounts to developers so that you can have fine grained
control over access to the repository (I assume it is because of that.
Otherwise I assume you would do what I have done, and that is create a "git"
user, with a home directory where you want to locate your repositories and
then tell your users to put the following sort of entry in .git/remotes/xxx
URL:git@host.com:repository.git
and in ~git/.ssh/authorized_keys putting all the developers public keys.
). But the example shows creating independant home directories for each of
the developers - but then limiting their access by giving them git-shell as
their shell.
I assume they would then user a .git/remotes entry of the form
URL:host.com:/absolute/path/to/repositories
My question, in this case is there any reason (such as git creating home
directoriy temp files or something) why each developer could not have their
home directory as the root of all the repositories (ie where my git user in
the above example had its home directory).
This would then mean each user (unless he had a real account on that machine)
would then use the following in .git/remotes
URL:host.com:repository.git
Which has the advantage of not revealing exactly where on your filesystem you
have chosen to store the repository (or more precisely allowing you to move
it without all users having to change their.git/remotes urls)
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ 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