* Re: [RFC PATCH (WIP)] Show a dirty working tree and a detached HEAD in status for submodule
From: Jens Lehmann @ 2010-01-12 16:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Johannes Schindelin, Shawn O. Pearce,
Heiko Voigt, Lars Hjemli
In-Reply-To: <7vtyusb6rv.fsf@alter.siamese.dyndns.org>
Am 11.01.2010 23:45, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> * It makes git show submodules as modified in the superproject when
>> one or more of these conditions are met:
>>
>> a) The submodule contains untracked files
>> b) The submodule contains modified files
>> c) The submodules HEAD is not on a local or remote branch
>>
>> That can be seen when using either "git status", "git diff[-files]"
>> & "git diff[-index] HEAD" (and with "git gui" & gitk).
>
> If the submodule is checked out, _and_ if the HEAD there, either detached
> or not, does not agree with what the "other" one records (i.e. the commit
> recorded in an entry in the index, or in the tree, that you are comparing
> your work tree against), then it also should be considered modified. I
> don't think your (a)-(c) cover this case.
Right, i did not to add the current (and unchanged) behavior to this
list, i just wrote down the new cases (and these new cases only come
into play when the submodule has been checked out).
> Also I don't understand why you want to treat (c) any specially at all.
To avoid possible loss of commits.
Before doing something like "git checkout -f" or "git reset --hard", it
is a good idea to check via "git status" if you have local changes. I
hope checkout and reset will recurse into submodules in the near future.
when they do, all commits in the submodule which are not on any branch
are lost (at least when the reflog expired). Or the remote branch the
user thinks the submodule is tracking has been deleted or rebased. You
might want to know that before e.g. committing it in the superproject.
Maybe compare it to new or modified files in a git repo: They don't
necessarily pose a problem when committing, you might be able to push
and clone the repo somewhere else and nothing breaks. But you wanna
know about these new and modifies files, in case you just forgot to add
them. So i think the HEAD of a submodule not on any branch is a bit like
a new or modified file in a regular repo, both will not show up in a
different repo than yours unless you do something about it. And a
modification is lost by a checkout or reset just as the dangling commits
will be.
Yes, this test can't provide 100% safety against loss of commits, but at
least we should try to warn if we can detect it. Does it give false
positives (saying the submodules HEAD is dangling when it shouldn't)?
I doubt it. Does it give false negatives? Yes, but we can't do anything
about that due to the distributed nature of git.
> Even if (c) is something we _should_ report, please do not call that as
> "detached" in its implementation.
Correct, that term is misleading in this context. Maybe call it
something like "The submodule contains a HEAD not on any branch"
then? Or "The submodule has a dangling HEAD"?
>> * This behavior is not configurable but activated by default. A config
>> option is needed here.
>
> I doubt it.
>
> My gut feeling is that this should be _always_ on for a submodule
> directory that has been "submodule init/update". The user is interested
> in that particular submodule, and any change to it should be reported for
> both classes of users. Theose who meant to use the submodule read-only
> need to be able to notice that they accidentally made the submodule dirty
> before making a commit in the superproject. Those who wanted to work in
> submodule needs to know if the state is in sync with what they expect
> before making a commit in the superproject.
Yes, me too thinks it should default to on for every initialized
submodule.
But this is a major change in behavior, so it might be a good idea to be
able to turn it off (e.g. if it breaks scripts). Maybe a config option
really isn't such a bright idea, but what about having something like a
"--no-dirty-submodules" command line option?
> That of course is provided if the unconditional check does not trigger for
> submodules that the user hasn't "submodue init"ed; I think you did that
> correctly at the beginning of your is_submodule_modified() implementation.
Yes, that's what that test is for. Will add a comment there.
> But the thing is, in a distributed environment, the submodule HEAD being
> at the tip of _some_ branch (either local or remote) you have doesn't mean
> anything to help them. IOW, for protect others, you would need a check
> when you _push out_ (either in 'push' or on the receiving end).
This is something on my TODO list: Add a change to "git push" to assert
that all HEADs of initialized submodules lie on a /remote/ branch before
doing the push in the superproject.
> So I'd suggest dropping this condition in "status/diff" that is about
> preparing to make the next commit in your _local_ history.
I would rather have this patch merged without c) than not at all. But i
think it is a worthwhile and rather cheap test. And i would prefer to
change the default behavior of "git status" only once now and not again
later.
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-12 16:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001110748560.13040@localhost.localdomain>
On Mon, Jan 11, 2010 at 07:59:18AM -0800, Linus Torvalds wrote:
> The meh news: this shows how grep is faster than regexec() due to being a
> smarter algorithm. For the non-fixed case (I used "qwerty.*as"), the
> numbers are
>
> - built-in:
> real 0m0.548s
> user 0m0.384s
> sys 0m0.152s
>
> - external:
> real 0m0.415s
> user 0m0.176s
> sys 0m0.160s
>
> so it really is just 'strstr()' that is faster. But This is a 'meh',
> because I don't really care, and the new code is still way faster than the
> old one. And I'd be personally willing to just drop the external grep if
> this is the worst problem.
Just for fun, I repeated my pcre tests on what's in pu (which has
Junio's lookahead patch now). Before they didn't show any improvement
because we wasted all of our time in non-regex code. There is some
improvement in just using pcre, but I didn't get any improvement by
tweaking it:
[pu]
$ time git grep 'qwerty.*as' >/dev/null
real 0m1.007s
user 0m0.752s
sys 0m0.252s
[pu + pcre]
$ time git grep --no-ext-grep 'qwerty.*as' >/dev/null
real 0m0.864s
user 0m0.648s
sys 0m0.212s
[pu + pcre_study]
$ time git grep --no-ext-grep 'qwerty.*as' >/dev/null
real 0m0.866s
user 0m0.628s
sys 0m0.200s
[pu + pcre_dfa_exec]
$ time git grep --no-ext-grep 'qwerty.*as' >/dev/null
real 0m0.868s
user 0m0.608s
sys 0m0.256s
So pcre seems to buy us about 15%, and tweaking it gets lost in the
noise (or I am tweaking it badly, which is entirely possible). I doubt
it's worth the trouble of supporting pcre for that much.
And let me add an additional vote against strstr:
$ time git grep --no-ext-grep qwerty >/dev/null
real 0m3.285s
user 0m3.032s
sys 0m0.252s
-Peff
^ permalink raw reply
* Re: default behaviour for `gitmerge` (no arguments)
From: Jeff King @ 2010-01-12 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gareth Adams, git
In-Reply-To: <7v7hrojukz.fsf@alter.siamese.dyndns.org>
On Mon, Jan 11, 2010 at 11:43:40AM -0800, Junio C Hamano wrote:
> The code indeed knows (as you can see "git pull" can figure it out) what
> other ref the current branch is configured to merge with by default.
> There is even a plumbing to do this for script writers.
>
> $ git for-each-ref --format='%(upstream)' $(git symbolic-ref HEAD)
>
> We can teach this short-hand to "git merge", perhaps:
>
> $ git merge --default
>
> But "no argument" cannot be the short-hand, because...
Hmm. If we had the oft-discussed-but-never-agreed-upon shorthand for
"the upstream of" then we wouldn't need a special merge option. You
could just do:
git merge %HEAD ;# (or git merge %, IIRC the proposal correctly)
-Peff
^ permalink raw reply
* Re: "What's cooking" incremental edition
From: Jeff King @ 2010-01-12 16:27 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e1001101221i389c05a8v7ff241859d5e8dae@mail.gmail.com>
On Sun, Jan 10, 2010 at 03:21:20PM -0500, Sverre Rabbelier wrote:
> On Sun, Jan 10, 2010 at 14:55, Junio C Hamano <gitster@pobox.com> wrote:
> > * jn/makefile (2010-01-06) 4 commits
> > - - Makefile: consolidate .FORCE-* targets
> > - - Makefile: learn to generate listings for targets requiring special flags
> > - - Makefile: use target-specific variable to pass flags to cc
> > - - Makefile: regenerate assembler listings when asked
> > + (merged to 'next' on 2010-01-10 at f5a5d42)
> > + + Makefile: consolidate .FORCE-* targets
> > + + Makefile: learn to generate listings for targets requiring special flags
> > + + Makefile: use target-specific variable to pass flags to cc
> > + + Makefile: regenerate assembler listings when asked
>
> Fwiw, I find it harder to read due to the now ambiguous meaning of the
> + and - (it could either mean something is in pu/next, or that the
> topic changed). Of course this is partly caused by the fact that I
> don't read emails in fixed font (by default), but perhaps it's worth
> considering using different symbols for pu/next-ness?
I agree. Plus line-by-line is not necessarily the most efficient way to
convey the information that a single character changed. If the subject
of the commit didn't change, it would be easier to see soemething like:
->+ Makefile: consolidate .FORCE-* targets
->+ Makefile: learn to generate listings for targets requiring special flags
etc (where ">" is supposed to indicate transition, but it's actually
quite ugly itself).
That being said, I don't personally see the incremental format as all
that useful. If I want to see increments of what's happening, I use git
itself. The "What's Cooking" message to me is about seeing a survey of
all topics, even those that haven't changed, with Junio's comments. So
you may take my suggestions with a large grain of salt. :)
-Peff
^ permalink raw reply
* Re: [PATCHv2 0/3] rebase-i: Ignore comments and blank lines among squash/fixup commands
From: Johannes Schindelin @ 2010-01-12 16:37 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, gitster
In-Reply-To: <cover.1263310175.git.mhagger@alum.mit.edu>
Hi,
On Tue, 12 Jan 2010, Michael Haggerty wrote:
> Here is v2 of the patch (now patch series) for making "rebase -i" ignore
> comments and blank lines while it is processing blocks of squash/fixup
> commands.
Me likee.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 4/4] ls-files: fix overeager pathspec optimization
From: Jeff King @ 2010-01-12 16:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Michael J Gruber, Jon Schewe, spearce
In-Reply-To: <1263022535-12822-4-git-send-email-gitster@pobox.com>
On Fri, Jan 08, 2010 at 11:35:35PM -0800, Junio C Hamano wrote:
> This patch changes the optimization so that it notices when the common
> prefix directory that it starts reading from is an ignored one.
Having just produced the similar but more ugly and messy patch earlier
in the thread, this series looks right to me.
-Peff
^ permalink raw reply
* Re: git-log - hide parent (was: merging two equivalent branches)
From: David Reitter @ 2010-01-12 16:59 UTC (permalink / raw)
To: git; +Cc: Christian MICHON, Christian Couder, Avery Pennarun
In-Reply-To: <201001080600.26088.chriscool@tuxfamily.org>
[-- Attachment #1.1: Type: text/plain, Size: 1234 bytes --]
On Jan 8, 2010, at 12:00 AM, Christian Couder wrote:
> What you could perhaps do with "git replace" or a graft is to change the
> merge commit so that it has only one parent instead of 2.
Thanks, also to Avery for his idea with "git .", which works well for me.
For the benefit of others, here's what I've done in the end in order to get rid of the extra 100,000 commits in the old upstream branch.
A very simple little script takes care of remapping the merges of the old upstream branch to the new one.
It takes the output of this
git log --since=2009-01-01 --format="%H %f"
on each of the two upstream branches and finds corresponding commits using the first commit line. With this alignment in place, we then need the list of merge commits that need to be redirected:
export BRANCHES='b1 b2 b3'
git log --since=2009-01-01 --author="my name" --format="%H %P" $BRANCHES
This can be fairly broad, but I didn't want BRANCHES to contain the upstream branches (even then it probably doesn't matter).
I then used a little piece of trivial code to apply the alignment to the parents of potential merge commits, to generate the grafts.
This is what's attached, in case anyone will find it useful.
[-- Attachment #1.2: make-grafts.py --]
[-- Type: text/x-python-script, Size: 3901 bytes --]
#!/usr/bin/python
# This will output a Git "grafts" file to use when a (set of) downstream branch(es)
# is to switch from merging with one upstream branch to another upstream branch, without
# keeping the full history of both upstream branches in the repository.
# If the upstream branches contain the same history information (semantically speaking),
# such as when they represent different conversions from an old CVS/SVN repository, then
# this script will find an alignment between them.
# The resulting grafts file will map past merges in the downstream branch to the new
# upstream branch, as if the old upstream branch never existed.
# If this works well, a "git filter-branch" should burn in the grafts so that they can
# be removed. (This is a history-changing operation.)
# See also:
# http://thread.gmane.org/gmane.comp.version-control.git/136377
# recommended usage:
#./make-grafts.py | sort | uniq > .git/info/grafts
# set input file names
upstream1 = "em-log"
upstream2 = "em-new-log"
mergecommits = "aq-merges"
# produce files:
# git checkout upstream1
# git log --since=2009-01-01 --format="%H %f">../emc/em-log
# git checkout upstream2
# git log --since=2009-01-01 --format="%H %f">../emc/em-new-log
# export BRANCHES='topic/b1 topic/b2 john jane master'
# git log --since=2009-01-01 --author="David Reitter" --format="%H %P" $BRANCHES >../emc/aq-merges; git log --since=2009-01-01 --merges --format="%H %P" $BRANCHES >>../emc/aq-merges
#################
import re
import sys
r1msgs = {}
r1revids = {}
# checkout emacs
# git log --since=2009-01-01 --format="%H %f">../emc/em-log
file = open(upstream1, 'r')
for l in file:
m = re.match("([a-f0-9]*) (.*)", l)
if m:
r1msgs[m.group(1)] = m.group(2)
r1revids[m.group(2)] = m.group(1)
file.close()
r2msgs = {}
r2revids = {}
# checkout emacs23
# git log --since=2009-01-01 --format="%H %f" >../emc/em-new-log
file = open(upstream2, 'r')
for l in file:
m = re.match("([a-f0-9]*) (.*)", l)
if m:
r2msgs[m.group(1)] = m.group(2)
r2revids[m.group(2)] = m.group(1)
file.close()
# checkout master
# export BRANCHES='23.1.undone Aquamacs22 dr-after-merge dr/dev dr/experimental dr/suedit master topic/NSAlertDialogs topic/dialogs topic/face-remapping topic/mac-support topic/menu-bar topic/minibuffer topic/option-key-remap topic/printing topic/python-mode topic/reconf topic/smart-spacing topic/spelling topic/tabbar topic/tmm topic/toolbar'
# git log --since=2009-01-01 --author="David Reitter" --merges --format="%H %P" $BRANCHES >../emc/aq-merges
# it's better to use all commits so we don't miss anything
# git log --since=2009-01-01 --author="David Reitter" --format="%H %P" $BRANCHES >../emc/aq-merges; git log --since=2009-01-01 --merges --format="%H %P" $BRANCHES >>../emc/aq-merges
def replace (revid):
if revid in r1msgs:
r1m = r1msgs[revid]
if r1m in r2revids:
r2r = r2revids[r1m]
if r2r:
return r2r
else:
print >> sys.stderr, "can't get mapping for revid "+revid+ r1m
else:
print >> sys.stderr, "can't find message of revid "+revid
return revid
# checkout master
#
file = open(mergecommits, 'r')
for l in file:
revids = l.rstrip().split(" ")
if revids:
# test:
# revids2 = revids
# for r in revids[1:]:
# r2 = replace(r)
# if r != r2:
# revids2 = revids2 + [r2]
# correct alternative
revids2 = [revids[0]] + map(replace, revids[1:])
if revids != revids2:
# make graft entry to write the merge such that it
# looks like the merge came from the other branch
print " ".join(revids2)
else:
print >> sys.stderr, "no remappings found for parents of merge revid "+" ".join(revids)
file.close()
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply
* Re: [PATCH 16/18] blob.c: remove unused function
From: Daniel Barkalow @ 2010-01-12 17:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1263282781-25596-17-git-send-email-gitster@pobox.com>
On Mon, 11 Jan 2010, Junio C Hamano wrote:
> parse_blob() is not used anywhere since a510bfa (Mark blobs as parsed when
> they're actually parsed, 2005-04-28).
Perhaps it should be replaced with a comment that blobs are never parsed,
because they don't need to be? We don't need the actual function, but I
think it's worth having a note where the function would be.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] remote-curl: Fix Accept header for smart HTTP connections
From: Shawn O. Pearce @ 2010-01-12 17:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
We actually expect to see an application/x-git-upload-pack-result
but we lied and said we Accept *-response. This was a typo on my
part when I was writing the code.
Fortunately the wrong Accept header had no real impact, as the
deployed git-http-backend servers were not testing the Accept
header before they returned their content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This should go in maint.
remote-curl.c | 2 +-
t/t5551-http-fetch.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index a331bae..8f169dd 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -480,7 +480,7 @@ static int rpc_service(struct rpc_state *rpc, struct discovery *heads)
strbuf_addf(&buf, "Content-Type: application/x-%s-request", svc);
rpc->hdr_content_type = strbuf_detach(&buf, NULL);
- strbuf_addf(&buf, "Accept: application/x-%s-response", svc);
+ strbuf_addf(&buf, "Accept: application/x-%s-result", svc);
rpc->hdr_accept = strbuf_detach(&buf, NULL);
while (!err) {
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index c0505ec..7faa31a 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -38,7 +38,7 @@ cat >exp <<EOF
> POST /smart/repo.git/git-upload-pack HTTP/1.1
> Accept-Encoding: deflate, gzip
> Content-Type: application/x-git-upload-pack-request
-> Accept: application/x-git-upload-pack-response
+> Accept: application/x-git-upload-pack-result
> Content-Length: xxx
< HTTP/1.1 200 OK
< Pragma: no-cache
--
1.6.6.280.ge295b
--
Shawn.
^ permalink raw reply related
* Re: default behaviour for `gitmerge` (no arguments)
From: Junio C Hamano @ 2010-01-12 18:11 UTC (permalink / raw)
To: Jeff King; +Cc: Gareth Adams, git
In-Reply-To: <20100112162355.GB25092@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Hmm. If we had the oft-discussed-but-never-agreed-upon shorthand for
> "the upstream of" then we wouldn't need a special merge option. You
> could just do:
>
> git merge %HEAD ;# (or git merge %, IIRC the proposal correctly)
I don't think "whatever _HEAD_ tracks" makes sense at the semantic level
(i.e. you don't do "branch.HEAD.merge") but a syntax for "whatever the
named _branch_ tracks" with "if a branch is not named, the current branch
is implied" (i.e. the one in parentheses) would.
It is an entirely different matter what the special syntax to trigger that
"upstream-ness" should be. I vaguely recall @{upstream} or @{u} were the
concensus?
^ permalink raw reply
* Interest in locking mechanism?
From: Edward Z. Yang @ 2010-01-12 18:10 UTC (permalink / raw)
To: git
I have a few friends that still use RCS for their version control
needs. We have argued over various points between RCS and Git, and
as far as I can tell the one thing RCS has that Git does not is
a locking mechanism. That is to say, co -l checks out a file and
also gives you a lock on it, preventing others from futzing with it,
and ci -u checks in the file and releases your lock. This is
useful if you have a shared working copy on a multiuser system or
on a network file system, and you don't want conflicts.
I was wondering if there would be interest in such a feature on
the Git developers side.
Cheers,
Edward
^ permalink raw reply
* Re: default behaviour for `gitmerge` (no arguments)
From: Jeff King @ 2010-01-12 18:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Gareth Adams, git
In-Reply-To: <7vhbqr2nxt.fsf@alter.siamese.dyndns.org>
On Tue, Jan 12, 2010 at 10:11:26AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Hmm. If we had the oft-discussed-but-never-agreed-upon shorthand for
> > "the upstream of" then we wouldn't need a special merge option. You
> > could just do:
> >
> > git merge %HEAD ;# (or git merge %, IIRC the proposal correctly)
>
> I don't think "whatever _HEAD_ tracks" makes sense at the semantic level
> (i.e. you don't do "branch.HEAD.merge") but a syntax for "whatever the
> named _branch_ tracks" with "if a branch is not named, the current branch
> is implied" (i.e. the one in parentheses) would.
The patch that Dscho provided would actually convert HEAD@{upstream}
into the upstream of whatever HEAD pointed at. Which I think makes
sense. We don't do it for reflogs, but that is because it is useful to
distinguish between the reflog for a symref and the thing it points to.
But since one would presumably not make such a configuration for a
symref, that distinction is not useful.
> It is an entirely different matter what the special syntax to trigger that
> "upstream-ness" should be. I vaguely recall @{upstream} or @{u} were the
> concensus?
Ah, right. I remembered hating "%" even as I typed it, but I had
forgotten about the followup discussion. Looking at it again, I note:
1. The last posted patch still has a misplaced free() (patch below),
but I think otherwise is not buggy.
2. We don't complain on "git show @{usptream}" and we probably should.
I remember there being some complications because the contents of
@{} were passed to approxidate, but I think we can get around that
by letting approxidate complain if _nothing_ in the date was
useful. So "git show @{2.weeks.and.7.hot.dogs.ago}" would still
work, but "git show @{totally.bogus.input}" would complain.
3. I have actually been running with Dscho's patch for the last couple
of months, and I don't remember using it once. So perhaps it is not
as useful as I might have thought. :)
Anyway, fixup patch is below. I don't expect you to pick up the topic or
anything, but since I went to the trouble to find the bug once upon a
time, I thought I would post the fix for anybody who does want to pick
it up.
diff --git a/sha1_name.c b/sha1_name.c
index b73b93e..da90ebe 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -275,9 +275,9 @@ static char *substitute_branch_name(const char **string, int *len)
char *ref = xstrndup(*string, *len - ret);
struct branch *tracking = branch_get(*ref ? ref : NULL);
- free(ref);
if (!tracking)
die ("No tracking branch found for '%s'", ref);
+ free(ref);
if (tracking->merge && tracking->merge[0]->dst) {
*string = xstrdup(tracking->merge[0]->dst);
*len = strlen(*string);
^ permalink raw reply related
* Re: Interest in locking mechanism?
From: B Smith-Mannschott @ 2010-01-12 18:29 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <1263319565-sup-1767@ezyang>
On Tue, Jan 12, 2010 at 19:10, Edward Z. Yang <ezyang@mit.edu> wrote:
> I have a few friends that still use RCS for their version control
> needs. We have argued over various points between RCS and Git, and
> as far as I can tell the one thing RCS has that Git does not is
> a locking mechanism. That is to say, co -l checks out a file and
> also gives you a lock on it, preventing others from futzing with it,
> and ci -u checks in the file and releases your lock. This is
> useful if you have a shared working copy on a multiuser system or
> on a network file system, and you don't want conflicts.
>
> I was wondering if there would be interest in such a feature on
> the Git developers side.
How do you imagine that this would work in a distributed system such
as git? What would it mean to have the lock for "a file", when each
user effectively has their own branch?
// Ben
^ permalink raw reply
* Re: Interest in locking mechanism?
From: Tomas Carnecky @ 2010-01-12 18:37 UTC (permalink / raw)
To: B Smith-Mannschott; +Cc: Edward Z. Yang, git
In-Reply-To: <28c656e21001121029h42544f3er6eedf8465851fec1@mail.gmail.com>
On 01/12/2010 07:29 PM, B Smith-Mannschott wrote:
> On Tue, Jan 12, 2010 at 19:10, Edward Z. Yang<ezyang@mit.edu> wrote:
>> I have a few friends that still use RCS for their version control
>> needs. We have argued over various points between RCS and Git, and
>> as far as I can tell the one thing RCS has that Git does not is
>> a locking mechanism. That is to say, co -l checks out a file and
>> also gives you a lock on it, preventing others from futzing with it,
>> and ci -u checks in the file and releases your lock. This is
>> useful if you have a shared working copy on a multiuser system or
>> on a network file system, and you don't want conflicts.
>>
>> I was wondering if there would be interest in such a feature on
>> the Git developers side.
>
> How do you imagine that this would work in a distributed system such
> as git? What would it mean to have the lock for "a file", when each
> user effectively has their own branch?
He mentioned a shared working copy, in which case there can be problems
if multiple users edit the same file.
Usually you'd work around that by cloning the repo, working in the
clone, and push the result back. This can get a bit tricky if the main
repository is not bare, but there is a solution even to that (either
explicitly run git reset --hard or have a post-receive hook which
updates the working tree).
tom
^ permalink raw reply
* Re: Interest in locking mechanism?
From: Edward Z. Yang @ 2010-01-12 18:33 UTC (permalink / raw)
To: B Smith-Mannschott; +Cc: git
In-Reply-To: <28c656e21001121029h42544f3er6eedf8465851fec1@mail.gmail.com>
Excerpts from B Smith-Mannschott's message of Tue Jan 12 13:29:41 -0500 2010:
> How do you imagine that this would work in a distributed system such
> as git? What would it mean to have the lock for "a file", when each
> user effectively has their own branch?
Hi Ben,
Good question. I don't intend for the locking mechanism to leak into
the distributed model of Git. It is solely for working copies, which /are/
centralized (just there can be a lot of them), when multiple people might
be editing the same working copy.
There is a somewhat natural question of: well, you should clone, make your
changes in your own copy, and then push them back. That is arguably the
correct mechanism. However, for casual users batonning changes from one
repository to another is often more overhead than is really necessary, and
I think a working copy locking mechanism will help for simple cases.
Cheers,
Edward
^ permalink raw reply
* [BUGFIX] Unbork remote helper execution
From: Ilari Liusvaara @ 2010-01-12 18:49 UTC (permalink / raw)
To: git
Someone that obiviously didn't test the change did the following (the
code blames to me, but I didn't write this):
code = start_command(helper);
if (code < 0 && errno == ENOENT)
die("Unable to find remote helper for '%s'", data->name);
else
exit(code);
Which is obiviously wrong. The code shouldn't exit if code is 0.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
transport-helper.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index fece6d6..7012101 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -121,7 +121,7 @@ static struct child_process *get_helper(struct transport *transport)
code = start_command(helper);
if (code < 0 && errno == ENOENT)
die("Unable to find remote helper for '%s'", data->name);
- else
+ else if (code != 0)
exit(code);
data->helper = helper;
--
1.6.6.102.gd6f8f.dirty
^ permalink raw reply related
* Re: Interest in locking mechanism?
From: Avery Pennarun @ 2010-01-12 19:01 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <1263319565-sup-1767@ezyang>
On Tue, Jan 12, 2010 at 1:10 PM, Edward Z. Yang <ezyang@mit.edu> wrote:
> I have a few friends that still use RCS for their version control
> needs. We have argued over various points between RCS and Git, and
> as far as I can tell the one thing RCS has that Git does not is
> a locking mechanism. That is to say, co -l checks out a file and
> also gives you a lock on it, preventing others from futzing with it,
> and ci -u checks in the file and releases your lock. This is
> useful if you have a shared working copy on a multiuser system or
> on a network file system, and you don't want conflicts.
If what you want is just one shared working copy with locking, then
what you want is RCS. Why change what's not broken? You're not doing
anything distributed or even any branching, and you don't need to
atomically commit multiple files at once (which would be very
confusing if more than one person is changing stuff in the current
tree), so git doesn't seem buy you anything.
There are lots of arguments that the central-shared-copy-with-locking
is obsolete. It's been obsolete since at least CVS (the "concurrent
versions system", named after the fact that you didn't have to have
one central working copy). But if you don't agree that this model is
obsolete, you might as well use a tool that treats your use case as a
first class citizen.
Have fun,
Avery
^ permalink raw reply
* Re: Interest in locking mechanism?
From: Edward Z. Yang @ 2010-01-12 19:11 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b131001121101i76ad8062p3a7f3571ad86b0ce@mail.gmail.com>
Excerpts from Avery Pennarun's message of Tue Jan 12 14:01:42 -0500 2010:
> If what you want is just one shared working copy with locking, then
> what you want is RCS. Why change what's not broken? You're not doing
> anything distributed or even any branching, and you don't need to
> atomically commit multiple files at once (which would be very
> confusing if more than one person is changing stuff in the current
> tree), so git doesn't seem buy you anything.
I would like to respectfully disagree. I want to use git because:
* I use Git on a regular basis, and do not use RCS. I constantly
have to go digging through the manpages when I occasionally do
stumble upon an RCS system. Interface familiarity is nice.
* Putting it in Git means that you can easily grow; you can decide
"Hey, maybe we want to do branchy development" and just do it,
rather than have to drum up the activation energy to do an
rcsimport.
* If code is deployed in a production context as a Git checkout,
you can definitely have both branchy development as well as
a shared working copy (with low contention, but contention nonetheless).
Cheers,
Edward
^ permalink raw reply
* Re: Interest in locking mechanism?
From: Avery Pennarun @ 2010-01-12 19:24 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <1263323292-sup-4182@ezyang>
On Tue, Jan 12, 2010 at 2:11 PM, Edward Z. Yang <ezyang@mit.edu> wrote:
> * I use Git on a regular basis, and do not use RCS. I constantly
> have to go digging through the manpages when I occasionally do
> stumble upon an RCS system. Interface familiarity is nice.
But the users who are arguing in favour RCS would say the opposite, right?
> * Putting it in Git means that you can easily grow; you can decide
> "Hey, maybe we want to do branchy development" and just do it,
> rather than have to drum up the activation energy to do an
> rcsimport.
But then you'd have to do an import now instead of later, for no
immediate gain. The extreme programming people would say YAGNI here;
delay the work until it's actually required, because it'll be no more
work later than it is right now.
> * If code is deployed in a production context as a Git checkout,
> you can definitely have both branchy development as well as
> a shared working copy (with low contention, but contention nonetheless).
I would suggest that by the time you're doing this, you're just lying
to yourself if you think you have RCS-style locking. People will
quite easy be able to change the same files as other people, then push
into git, and sooner or later someone will have to pull from git into
the original shared repository, possibly stomping on other people's
work. So you end up not having the advantage you were trying to
achieve.
BTW, I will try be a bit more constructive in case you *really* want
this: I've never heard of anyone doing RCS-style locking with git, so
you're probably out of luck if you're looking for a pre-made solution.
But it's probably rather easy to construct a simple shell script
implementation that's independent of your revision control system
(since locking files has nothing to do with revision tracking,
really). Just make a 'co' command that writes your username to
.filename.lock and chmods the file; then write a ci command that
checks the lockfile to make sure it's yours, deletes the lock file,
git commits it, and chmods the file back again.
Have fun,
Avery
^ permalink raw reply
* Re: Interest in locking mechanism?
From: Martin Langhoff @ 2010-01-12 19:26 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: Avery Pennarun, git
In-Reply-To: <1263323292-sup-4182@ezyang>
On Tue, Jan 12, 2010 at 8:11 PM, Edward Z. Yang <ezyang@mit.edu> wrote:
> I would like to respectfully disagree. I want to use git because:
I have to say, Avery's got a very good point, and my position (as a
cross SCM user) is that he's right. But I have two suggestions that
might work to at least try out what you say you want...:
- Write a wrapper around your editor invokation to call `flock $EDITOR $@`
- Use rcs on top of git, just for the locking -- write a commit hook
that auto-commits to rcs when you commit to git; add suitable excludes
so git doesn't worry about ,v files.
And a comment on your points -
> * I use Git on a regular basis, and do not use RCS. I constantly
> have to go digging through the manpages when I occasionally do
> stumble upon an RCS system. Interface familiarity is nice.
that's very weak. Write your our wrappers that mimic git commands you
want to use...
> * Putting it in Git means that you can easily grow; you can decide
> "Hey, maybe we want to do branchy development" and just do it,
> rather than have to drum up the activation energy to do an
> rcsimport
"Drum up the energy" is somewhat exaggerated ;-)
> * If code is deployed in a production context as a Git checkout,
If that's what you are doing (or will be doing), just drop rcs, and
explore workflows that help bring attention to any case where there
were edits on the same file.
Actually -- you can focus on workflows that prevent or highlight cases
where the same file is "being edited" in a pre-commit hook that checks
and warns...
- if new commits (on the matching branch) touch the file (evil: will
have to do git-fetch)
- if the file was committed recently by a different committer
- if we're committing a merge involving files changing on more than
one of the heads involved (this case can sometimes be auto-merged with
a diff3-like algorythm)
maybe something on that track helps
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Interest in locking mechanism?
From: Martin Langhoff @ 2010-01-12 19:33 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Edward Z. Yang, git
In-Reply-To: <32541b131001121124u541de280na9184183d8704dc8@mail.gmail.com>
On Tue, Jan 12, 2010 at 8:24 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> really). Just make a 'co' command that writes your username to
> .filename.lock and chmods the file; then write a ci command that
> checks the lockfile to make sure it's yours, deletes the lock file,
> git commits it, and chmods the file back again.
Actually -- on the same track but even better: if you are using a
unixy system, you are likely to have all the users belong to a group,
and the files are editable by the group because they are rwx by group
members.
So write your own "git-lock" command that does "chmod g-w $@";
git-unlock reenables the group-writable bit. Done.
For more arcane things, use ACLs. On Windows I am sure there is a
commandline tool to touch ACL bits.
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Interest in locking mechanism?
From: Edward Z. Yang @ 2010-01-12 19:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Avery Pennarun, git
In-Reply-To: <46a038f91001121133r62b3d748n38ca27234f18e960@mail.gmail.com>
Excerpts from Martin Langhoff's message of Tue Jan 12 14:33:18 -0500 2010:
> So write your own "git-lock" command that does "chmod g-w $@";
> git-unlock reenables the group-writable bit. Done.
That was what I was thinking of doing (with modestly more cleverness for
recursive operation), and maybe some convenience flags for git-commit
for automatically unlocking or preserving the lock across a commit.
Cheers,
Edward
^ permalink raw reply
* Re: [BUGFIX] Unbork remote helper execution
From: Johannes Sixt @ 2010-01-12 19:53 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Junio C Hamano, git
In-Reply-To: <1263321344-21237-1-git-send-email-ilari.liusvaara@elisanet.fi>
[added git@vger]
On Dienstag, 12. Januar 2010, Ilari Liusvaara wrote:
> Someone that obiviously didn't test the change did the following (the
> code blames to me, but I didn't write this):
>
> code = start_command(helper);
> if (code < 0 && errno == ENOENT)
> die("Unable to find remote helper for '%s'", data->name);
> else
> exit(code);
>
> Which is obiviously wrong. The code shouldn't exit if code is 0.
Duh! Sorry for that. Your original code indeed has 'else if (code != 0)'.
Thanks for catching this. BTW, the test suite passes nevertheless.
Aren't there any tests that exercise the code path, or do I have them
disabled somehow? So, yes: I didn't test the change.
Here is the amended commit that replaces the tip of js/exec-error-report,
with some light testing this time.
--- 8< ---
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Subject: [PATCH] Improve error message when a transport helper was not found
Perviously, the error message was:
git: 'remote-foo' is not a git-command. See 'git --help'.
By not treating the transport helper as a git command, a more suitable
error is reported:
fatal: Unable to find remote helper for 'foo'
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
transport-helper.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 6ece0d9..7dce4a4 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -102,6 +102,7 @@ static struct child_process *get_helper(struct transport *transport)
int refspec_nr = 0;
int refspec_alloc = 0;
int duped;
+ int code;
if (data->helper)
return data->helper;
@@ -111,13 +112,18 @@ static struct child_process *get_helper(struct transport *transport)
helper->out = -1;
helper->err = 0;
helper->argv = xcalloc(4, sizeof(*helper->argv));
- strbuf_addf(&buf, "remote-%s", data->name);
+ strbuf_addf(&buf, "git-remote-%s", data->name);
helper->argv[0] = strbuf_detach(&buf, NULL);
helper->argv[1] = transport->remote->name;
helper->argv[2] = remove_ext_force(transport->url);
- helper->git_cmd = 1;
- if (start_command(helper))
- die("Unable to run helper: git %s", helper->argv[0]);
+ helper->git_cmd = 0;
+ helper->silent_exec_failure = 1;
+ code = start_command(helper);
+ if (code < 0 && errno == ENOENT)
+ die("Unable to find remote helper for '%s'", data->name);
+ else if (code != 0)
+ exit(code);
+
data->helper = helper;
data->no_disconnect_req = 0;
--
1.6.6.115.gd1ab3
^ permalink raw reply related
* Re: Interest in locking mechanism?
From: Avery Pennarun @ 2010-01-12 20:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Edward Z. Yang, git
In-Reply-To: <46a038f91001121133r62b3d748n38ca27234f18e960@mail.gmail.com>
On Tue, Jan 12, 2010 at 2:33 PM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> On Tue, Jan 12, 2010 at 8:24 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>> really). Just make a 'co' command that writes your username to
>> .filename.lock and chmods the file; then write a ci command that
>> checks the lockfile to make sure it's yours, deletes the lock file,
>> git commits it, and chmods the file back again.
>
> Actually -- on the same track but even better: if you are using a
> unixy system, you are likely to have all the users belong to a group,
> and the files are editable by the group because they are rwx by group
> members.
>
> So write your own "git-lock" command that does "chmod g-w $@";
> git-unlock reenables the group-writable bit. Done.
The trick is to track which user has the file checked out; you don't
want some random person to (accidentally) check in someone else's
file. That's the whole point. Of course, you can arrange for this
with some simple shell scripting.
I doubt ACLs are needed really. RCS certainly works(1) fine without them.
Have fun,
Avery
(1) depending on your definition of "works"
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Johannes Sixt @ 2010-01-12 21:13 UTC (permalink / raw)
To: kusmabite; +Cc: Dmitry Potapov, msysgit, git, Andrzej K. Haczewski
In-Reply-To: <40aa078e1001080258n67e0711sf4733a99d512bf1@mail.gmail.com>
On Freitag, 8. Januar 2010, Erik Faye-Lund wrote:
> On Fri, Jan 8, 2010 at 4:32 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > AFAIK, Win32 API assumes that reading LONG is always atomic, so
> > the critical section is not really necesary here, but you need
> > to declare 'waiters' as 'volatile':
>
> "Simple reads and writes to properly-aligned 32-bit variables are
> atomic operations."
> http://msdn.microsoft.com/en-us/library/ms684122(VS.85).aspx
But then the next sentence is:
"However, access is not guaranteed to be synchronized. If two threads are
reading and writing from the same variable, you cannot determine if one
thread will perform its read operation before the other performs its write
operation."
This goes without saying, IOW, those Microsofties don't know what they write,
which makes the documentation a bit less trustworthy.
Nevertheless, I rewrote the code to use Interlocked* functions, and then read
the documentation again. InterlockedIncrement reads, for example:
"... This function is atomic with respect to calls to other interlocked
functions."
In particular, it doesn't say that it is atomic WRT reads such as we have
here:
> >> + /* we're done waiting, so make sure we decrease waiters count */
> >> + EnterCriticalSection(&cond->waiters_lock);
> >> + --cond->waiters;
> >> + LeaveCriticalSection(&cond->waiters_lock);
I've no assembly-fu, but I could imagine that it does not matter, but I really
would have confirmation from an x86 guru.
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox