* Permissions and authorisations in git repository
From: vikram2rhyme @ 2011-01-28 11:41 UTC (permalink / raw)
To: git
Hello friends
I am wondering if there are any permission and authorization control over
git
repository. I have gone through git manual but there is no discussion on it.
On the internet i searched but hardy i found anything. Please help me if
there
is any permission control in distributed environment in git repository
--
View this message in context: http://git.661346.n2.nabble.com/Permissions-and-authorisations-in-git-repository-tp5969556p5969556.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Why git tags are there in git?
From: vikram2rhyme @ 2011-01-28 11:37 UTC (permalink / raw)
To: git
Hello friends
I am wondering why the tags are there in git. As they are just pointer to
the commit
we can refer those commit by SHA sum only then why tagging? Moreover a
commit can
be tagged more than once that result in multiple tags pointing to the same
point in the history.
Is this a design flaw?
--
View this message in context: http://git.661346.n2.nabble.com/Why-git-tags-are-there-in-git-tp5969544p5969544.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] git-gui: fix browser with initial path
From: Bert Wesarg @ 2011-01-28 11:04 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git
In-Reply-To: <87sjwdmhrs.fsf@fox.patthoyts.tk>
On Fri, Jan 28, 2011 at 11:42, Pat Thoyts
<patthoyts@users.sourceforge.net> wrote:
> The commit comment for this doesn't really reflect whats being
> done. Commit 1ab8628 fixed the [Up To Parent] problem and this just
> fixes the display on the browser title.
>
> So I plan to take this with the commit comment as:
>
> git-gui: fix display of path in browser title
>
> Ensure the browser path is shown on the title with a / suffix and escape
> any backslashes or newlines in path elements before display.
No, the main problem is, that the path does not end in a slash, but
the browser code expect this, ie. it build sub pathes by just
concatenating '$path' and '$file', or with '$dir/', without a slash
inbetween. Its not only the visual part. Try this without the patch
(int git.git):
git gui browse git-gui/
In the path line there should be now 'master:git-gui'. Than go into
'lib'. You have 'master:git-guilib/'. And than double click about.tcl,
The blame view will get the 'git-guilib/about.tcl'.
Because the browser is itself consistent in this behavior, the only
problem was when the browser was a path given to start with. And this
path needs have a trailing slash. And this patch ensures this.
Bert
>
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>
> --
> Pat Thoyts http://www.patthoyts.tk/
> PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
>
>
^ permalink raw reply
* Re: [PATCH] git-gui: fix browser with initial path
From: Pat Thoyts @ 2011-01-28 10:42 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Shawn O. Pearce, git
In-Reply-To: <AANLkTim8BhN9czr6Jx5J28iNop4XdFDcNKbbjxddW9-i@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
>Ping.
>
>On Tue, Nov 23, 2010 at 08:37, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>> The path given to the browser does not end in a slash, which results in bad
>> path given to blame and broke [Up To Parent]. Also the path was not
>> escaped before displaying.
>>
>> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>>
>> ---
>> git-gui/lib/browser.tcl | 8 +++++++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/git-gui/lib/browser.tcl b/git-gui/lib/browser.tcl
>> index c241572..a88a68b 100644
>> --- a/git-gui/lib/browser.tcl
>> +++ b/git-gui/lib/browser.tcl
>> @@ -26,8 +26,14 @@ constructor new {commit {path {}}} {
>> wm withdraw $top
>> wm title $top [append "[appname] ([reponame]): " [mc "File Browser"]]
>>
>> + if {$path ne {}} {
>> + if {[string index $path end] ne {/}} {
>> + append path /
>> + }
>> + }
>> +
>> set browser_commit $commit
>> - set browser_path $browser_commit:$path
>> + set browser_path "$browser_commit:[escape_path $path]"
>>
>> ${NS}::label $w.path \
>> -textvariable @browser_path \
>> --
>> tg: (6f10c41..) bw/git-gui/fix-browser-up (depends on: master)
>>
>
The commit comment for this doesn't really reflect whats being
done. Commit 1ab8628 fixed the [Up To Parent] problem and this just
fixes the display on the browser title.
So I plan to take this with the commit comment as:
git-gui: fix display of path in browser title
Ensure the browser path is shown on the title with a / suffix and escape
any backslashes or newlines in path elements before display.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH 1/8] git-gui: rework handling of diff header
From: Pat Thoyts @ 2011-01-28 9:43 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Shawn O. Pearce, git, Johannes Sixt
In-Reply-To: <babc4fe91e54e3923baa6f08cc92ee8ea494e704.1291927657.git.bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
>The fix in ca53c3f (Fix diff parsing for lines starting with "--" or "++",
>2008-09-05) got a bug report from Johannes Sixt, that new files in the
>index now looks like:
>
>new file mode 100644
>--- /dev/null
>+++ b/foo
>@@ -0,0 +1 @@
>+foo
Inlining this in the commit comment causes 'git am' to terminate the
comment text early. You should add some leading space when putting text
that looks like patch header into this section.
>
>The introduced problem was that the 'in-diff-header'-flag was unconditially
>disabled. Now it is only disabled when a hunk line is detected. And also
>re-enabled when we encounter a new diff header.
>
>The second part solves also the issue reported by me for diffs with file
>type changes (i.e. the ''error: Unhandled 2 way diff marker: {d}"', which
>comes from the second 'diff --git' line).
>
>Reported-by: Johannes Sixt <j.sixt@viscovery.net>
>Reported-by: Bert Wesarg <bert.wesarg@googlemail.com>
>Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>
>---
>
>Cc: Johannes Sixt <j.sixt@viscovery.net>
>---
> foo | 1 +
> lib/diff.tcl | 18 +++++++++++++++---
> 2 files changed, 16 insertions(+), 3 deletions(-)
> create mode 100644 foo
>
>diff --git a/foo b/foo
>new file mode 100644
>index 0000000..257cc56
>--- /dev/null
>+++ b/foo
>@@ -0,0 +1 @@
>+foo
We don't need a 'foo' file :)
>diff --git a/lib/diff.tcl b/lib/diff.tcl
>index 9d0dc07..dae6ca6 100644
>--- a/lib/diff.tcl
>+++ b/lib/diff.tcl
>@@ -382,23 +382,35 @@ proc read_diff {fd conflict_size cont_info} {
> foreach {line markup} [parse_color_line $line] break
> set line [string map {\033 ^} $line]
>
>- # -- Cleanup uninteresting diff header lines.
>+ # -- Check for start of diff header.
>+ if { [string match {diff --git *} $line]
>+ || [string match {diff --cc *} $line]
>+ || [string match {diff --combined *} $line]} {
>+ set ::current_diff_inheader 1
>+ }
>+
>+ # -- Check for end of diff header (any hunk line will do this).
> #
>+ if {[regexp {^@@+ } $line]} {set ::current_diff_inheader 0}
>+
> if {$::current_diff_inheader} {
>+ append current_diff_header $line "\n"
>+
>+ # -- Cleanup uninteresting diff header lines.
>+ #
> if { [string match {diff --git *} $line]
> || [string match {diff --cc *} $line]
> || [string match {diff --combined *} $line]
> || [string match {--- *} $line]
> || [string match {+++ *} $line]} {
>- append current_diff_header $line "\n"
> continue
> }
> }
>+
> if {[string match {index *} $line]} continue
> if {$line eq {deleted file mode 120000}} {
> set line "deleted symlink"
> }
>- set ::current_diff_inheader 0
>
> # -- Automatically detect if this is a 3 way diff.
> #
The patch series 1 to 8 are fine. I've taken them without the foo file
mentioned above and adding some spaces to the commit comment as noted
above. This replaces a couple of tentative patches we've discussed
previously for errors on stderr when symlinks replace files.
Thank you - applying to master.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* add command clean to git help
From: redstun @ 2011-01-28 9:43 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTikNx-yi5FsK3vVv7MRCxNfEQOM+O5a8EssdpCN3@mail.gmail.com>
Just realized in git help the command clean is not mentioned, yet
#git --version
git version 1.7.3.3
^ permalink raw reply
* Re: Project- vs. Package-Level Branching in Git
From: Jakub Narebski @ 2011-01-28 9:38 UTC (permalink / raw)
To: Thomas Hauk; +Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <15B7CA2E-C584-4563-B9E3-D80861CD9565@shaggyfrog.com>
Thomas Hauk <tom@shaggyfrog.com> writes:
> On Jan 27, 2011, at 12:53 PM, Ævar Arnfjörð Bjarmason wrote:
> > You'll be much better off if you have project-specific repositories.
>
> But how often do you have a project that has no external or internal
> dependencies on any other packages or libraries? Any project I've
> ever done, big or small, has relied on some existing
> codebase. Imagine a project that uses liba and libb, which both
> reference libc. To use Git, I'd have to have copies of libc existing
> in three repositories, and copies of liba and lib in two
> repositories each. What a nightmare... and that's only a trivial
> hypothetical example.
That is only if lib{a,b,c} is _internal_ dependency. In usual case
project A might depend on library B *to be installed*, but it doesn't
mean that source code of library B has to be in repository for project
A. And in usual case when project A depends on library B, it relies
on library B public stable API (its build system might check if you
have new enough library B installed). If you depend on specific
version of library, patched, that is your problem...
In the case of internal dependency, where you co-develop both project
A and library B, it makes most sense to have separate repositories for
A and for B, and tie them up using submodules or subtree merge.
In the case you describe you would need three *checkouts* of libc (if
checkout is needed for development, see above), but not necessary
three copies (three clones) of libc *repository* - one copy should be
enough.
>
> I understand that Git was designed with a specific feature set in
> mind -- to manage Linux kernel development -- and as such isn't
> going to satisfy everyone. But I'm having trouble figuring out how
> to integrate it as the SCM in my projects, which aren't organized
> any differently than any other projects I've seen.
Well, you are braindamaged by your SCM ;-) ... just kidding.
Take a look how LibreOffice (Go-OOo), KDE, GNOME, GNU SourceMage Linux
distribution organize their repositories -- all of them are highly
modular / componentized.
> Surely I can't be the only person with these difficulties? Git just
> doesn't seem to scale when it comes to componentized projects. Do
> other distributed VCSs work better than Git in this respect?
Perhaps you could abuse Bazaar in that fashion, but I think most DVCS
use branching of whole project (branch in repository) model, rather
than the branching is copying (branch is folder) model that Perforce
and Subversion use.
Whole project branching has just too many advantages, or conversely
branch as folder (directory) has too many disadvantages.
> I'm really trying to get on the Git bandwagon, here.
World domination is not on agenda :-) The main goal of Git is to make
it easy for open-source projects to collaborate.
P.S. There are commercial DVCS: BitKeeper, Vault,...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] git-gui: fix typo in image data
From: Pat Thoyts @ 2011-01-28 9:34 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Shawn O. Pearce, Gustaf Hendeby, git
In-Reply-To: <c373e73fb114ebc580c36bc494dc62f80a19ece9.1291927374.git.bert.wesarg@googlemail.com>
This patchset look fine - thank you, applying to master.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [RFC] Add --create-cache to repack
From: Johannes Sixt @ 2011-01-28 9:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Nicolas Pitre, John Hawley
In-Reply-To: <1296201984-24426-1-git-send-email-spearce@spearce.org>
Am 1/28/2011 9:06, schrieb Shawn O. Pearce:
> A cache pack is all objects reachable from a single commit that is
> part of the project's stable history and won't disappear, and is
> accessible to all readers of the repository. By containing only that
> commit and its contents, if the commit is reached from a reference we
> know immediately that the entire pack is also reachable. To help
> ensure this is true, the --create-cache flag looks for a commit along
> refs/heads and refs/tags that is at least 1 month old, working under
> the assumption that a commit this old won't be rebased or pruned.
In one of my repositories, I have two stable branches and a good score of
topic branches of various ages (a few hours up to two years 8). The topic
branches will either be dropped eventually, or rebased.
What are the odds that this choice of a tip commit picks one that is in a
topic branch? Or is there no point in using --create-cache in a repository
like this?
-- Hannes
^ permalink raw reply
* Re: Project- vs. Package-Level Branching in Git
From: Jay Soffian @ 2011-01-28 8:30 UTC (permalink / raw)
To: Thomas Hauk; +Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <15B7CA2E-C584-4563-B9E3-D80861CD9565@shaggyfrog.com>
On Thu, Jan 27, 2011 at 6:22 PM, Thomas Hauk <tom@shaggyfrog.com> wrote:
> Git just doesn't seem to scale when it comes to componentized projects.
With git the canonical approach, such that it is, is for each
component to be its own repo. You then tie the repos together into a
project using submodules:
- http://progit.org/book/ch6-6.html
- http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
However, submodules can be a challenge to work with, and so there have
been other attempts at tying multiple repos together such as:
- http://source.android.com/source/git-repo.html
- https://github.com/apenwarr/git-subtree
j.
^ permalink raw reply
* [RFC] Add --create-cache to repack
From: Shawn O. Pearce @ 2011-01-28 8:06 UTC (permalink / raw)
To: git, Junio C Hamano, Nicolas Pitre; +Cc: John Hawley
A cache pack is all objects reachable from a single commit that is
part of the project's stable history and won't disappear, and is
accessible to all readers of the repository. By containing only that
commit and its contents, if the commit is reached from a reference we
know immediately that the entire pack is also reachable. To help
ensure this is true, the --create-cache flag looks for a commit along
refs/heads and refs/tags that is at least 1 month old, working under
the assumption that a commit this old won't be rebased or pruned.
During a clone request if a commit is discovered that matches the
cache pack, all newer objects can be enumerated using normal rules and
sent to the client, and then the cache pack can be simply appended
onto the end of the stream. There is no need to enumerate the objects
as the object count is in the header of the cache pack. There is no
need to allocate all of the objects in the pack-objects process, which
reduces its working set size, and its impact on busy servers.
By keeping the pack with a standard .keep file, later repacks of the
repository won't include these objects, which permits disk usage to
stay within a reasonable factor of the repository size.
Because newer packed objects are not delta compressed against the
older cached pack, clients may receive a larger data transfer when the
cached pack is simply appended onto the stream. pack-objects could
work around this by constructing a thin pack, and adding the cache
pack's tip commit as the uninteresting/common base for the thin pack.
The references for the newer objects will point to older data behind
them so they will automatically use the larger REF_DELTA format.
This commit only adds the logic to git-repack to construct the cached
pack. For example on a Linux kernel repository:
# Construct the initial cache pack
$ git repack --create-cache --cache-include=v2.6.11-tree
# Remove duplicated objects
$ git repack -a -d
If this is actually a good idea, pack-objects can later learn how to
use $GIT_DIR/objects/info/cached during revision traversal to know
when a cached pack is found, and switch to the thin pack + cached pack
transfer method described above.
The cached pack is only useful for initial clones of a repository, and
only if object enumeration takes more than a few seconds. However
initial clones of big projects like linux-2.6.git are killing some
common mirror sites, so this could be one way to help them out.
Later fetch-pack/upload-pack protocol could learn how to more
intelligently use the cached pack in the data stream, allowing a
client whose connection has been broken to resume with a byte range
request within the cached pack, assuming the pack is still present on
the server. This can be validated by giving the client both the SHA-1
pack name, and the SHA-1 trailer of the pack content, and requiring
these to match on a byte range request.
Repository owners may also enjoy having the cached pack as frequent
`git gc` invocations will now have lower IO and CPU requirements due
to the large pack having a .keep file. In the future `git gc --auto`
could learn to suggest removing the .keep file and regenerating the
cached pack once there is sufficient new content to make creating a
new pack worthwhile.
---
git-repack.sh | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 624feec..7a7984c 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -15,6 +15,9 @@ F pass --no-reuse-object to git-pack-objects
n do not run git-update-server-info
q,quiet be quiet
l pass --local to git-pack-objects
+create-cache create a cached pack for older history
+cache-include= other objects to include in the cache
+cache-age= how old to start caching from
Packing constraints
window= size of the window used for delta compression
window-memory= same as the above, but limit memory size instead of entries count
@@ -26,6 +29,7 @@ SUBDIRECTORY_OK='Yes'
no_update_info= all_into_one= remove_redundant= unpack_unreachable=
local= no_reuse= extra=
+create_cache= cache_include= cache_age=1.month.ago
while test $# != 0
do
case "$1" in
@@ -38,6 +42,11 @@ do
-f) no_reuse=--no-reuse-delta ;;
-F) no_reuse=--no-reuse-object ;;
-l) local=--local ;;
+ --create-cache) create_cache=t ;;
+ --cache-age) cache_age=$2; shift ;;
+ --cache-include)
+ name=$(git rev-parse --verify $2)
+ cache_include="$cache_include $name"; shift ;;
--max-pack-size|--window|--window-memory|--depth)
extra="$extra $1=$2"; shift ;;
--) shift; break;;
@@ -52,16 +61,19 @@ true)
esac
PACKDIR="$GIT_OBJECT_DIRECTORY/pack"
+INFODIR="$GIT_OBJECT_DIRECTORY/info"
PACKTMP="$PACKDIR/.tmp-$$-pack"
rm -f "$PACKTMP"-*
trap 'rm -f "$PACKTMP"-*' 0 1 2 3 15
# There will be more repacking strategies to come...
-case ",$all_into_one," in
-,,)
+case ",$create_cache,$all_into_one," in
+,t,,)
+ ;;
+,,,)
args='--unpacked --incremental'
;;
-,t,)
+,,t,)
args= existing=
if [ -d "$PACKDIR" ]; then
for e in `cd "$PACKDIR" && find . -type f -name '*.pack' \
@@ -84,9 +96,22 @@ esac
mkdir -p "$PACKDIR" || exit
-args="$args $local ${GIT_QUIET:+-q} $no_reuse$extra"
-names=$(git pack-objects --keep-true-parents --honor-pack-keep --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
- exit 1
+if [ -n "$create_cache" ]; then
+ root=$(git rev-list -n 1 --until=$cache_age --branches --tags --)
+ args="$args ${GIT_QUIET:+-q} $no_reuse$extra"
+ names=$( ( echo "$root";
+ for name in $cache_include
+ do
+ echo "$name"
+ done ) |
+ git pack-objects --keep-true-parents --non-empty $args --revs \
+ "$PACKTMP") ||
+ exit 1
+else
+ args="$args $local ${GIT_QUIET:+-q} $no_reuse$extra"
+ names=$(git pack-objects --keep-true-parents --honor-pack-keep --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
+ exit 1
+fi
if [ -z "$names" ]; then
say Nothing new to pack.
fi
@@ -151,6 +176,10 @@ do
mv -f "$PACKTMP-$name.pack" "$PACKDIR/pack-$name.pack" &&
mv -f "$PACKTMP-$name.idx" "$PACKDIR/pack-$name.idx" ||
exit
+
+ if [ -n "$create_cache" ]; then
+ echo "cache $root$cache_include" >"$PACKDIR/pack-$name.keep"
+ fi
done
# Remove the "old-" files
@@ -162,6 +191,22 @@ done
# End of pack replacement.
+# Update the cache list
+if [ -n "$create_cache" ]; then
+ mkdir -p "$INFODIR" || exit
+ ( echo "+ $root" &&
+ for name in $cache_include
+ do
+ echo "+ $name"
+ done
+ for name in $names
+ do
+ echo "P $name"
+ done ) >"$INFODIR/cached"
+ echo "Cached from:"
+ git log --pretty=format:' [%h] %cd%n %s' -1 "$root" --
+fi
+
if test "$remove_redundant" = t
then
# We know $existing are all redundant.
--
1.7.4.rc1.253.gb7420
^ permalink raw reply related
* Re: [PATCH] git-gui: add config value gui.diffopts for passing additional diff options
From: Johannes Sixt @ 2011-01-28 7:29 UTC (permalink / raw)
To: Tilman Vogel; +Cc: Pat Thoyts, Git Mailing List
In-Reply-To: <4D420B95.2060509@web.de>
Am 1/28/2011 1:19, schrieb Tilman Vogel:
> Am 25.01.2011 01:25, schrieb Pat Thoyts:
>> This seems ok but you don't say what it is for. Why do you want to be
>> able to pass additional options to git diff?
>
> Sorry, forgot to copy the motivation from
> <https://github.com/git/git/pull/8>:
>
> I want to be able to make diff ignore whitespace changes "-b". But maybe
> someone else wants "-w" or what not, so I think a generic option field
> is most versatile.
What do you expect to happen, when a user writes any of the following in
that edit box?
--name-status
-R
--frotz
origin master
Don't you want to diagnose bogus input?
Disable "Stage/Unstage hung/lines" (because they won't apply anymore)?
Etc.
I don't think this is a great improvement. At the least it is not thought
through.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-gui: add config value gui.diffopts for passing additional diff options
From: Tilman Vogel @ 2011-01-28 0:19 UTC (permalink / raw)
Cc: git
In-Reply-To: <87ipxdn81f.fsf@fox.patthoyts.tk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
Am 25.01.2011 01:25, schrieb Pat Thoyts:
> This seems ok but you don't say what it is for. Why do you want to be
> able to pass additional options to git diff?
Sorry, forgot to copy the motivation from
<https://github.com/git/git/pull/8>:
I want to be able to make diff ignore whitespace changes "-b". But maybe
someone else wants "-w" or what not, so I think a generic option field
is most versatile.
If you feel, this switch should be easier to reach than through the
options menu, I agree, but I am a Tcl/Tk newbie, so this was the easiest
fix for me.
> I can apply this to git-gui's repository. The Documentation change will
> need to be sent to git separately once this is merged from git-gui.
Sure, I would be happy. However, if you feel like coding up something
that's easier to use, I'd be even happier. But maybe the generic field
is still of use.
Regards,
Tilman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk1CC5UACgkQ9ZPu6Yae8lknCwCfcEfBH8uSSZbB93IHpJiEivll
zlwAoKgPswZGMf6fERRB8p24TsLCGA1r
=uWHw
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] git-p4: Corrected typo.
From: Vitor Antunes @ 2011-01-27 23:35 UTC (permalink / raw)
To: git; +Cc: Vitor Antunes
In-Reply-To: <1290648419-6107-1-git-send-email-vitor.hda@gmail.com>
Hi everyone,
Could anyone comment the 3 patches I sent (being this the last one)?
Thanks in advance,
Vitor
On Thu, Nov 25, 2010 at 1:26 AM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> ---
> contrib/fast-import/git-p4 | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 0ea3a44..a466847 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -618,7 +618,7 @@ class P4Submit(Command):
> if len(detectRenames) > 0:
> diffOpts = "-M%s" % detectRenames
> else:
> - diffOpts = ("", "-M")[self.detectRenames]
> + diffOpts = ("", "-M")[self.detectRename]
>
> detectCopies = gitConfig("git-p4.detectCopies")
> if len(detectCopies) > 0:
> --
> 1.7.2.3
>
>
--
Vitor Antunes
^ permalink raw reply
* Re: Project- vs. Package-Level Branching in Git
From: Thomas Hauk @ 2011-01-27 23:22 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <AANLkTinTRgzv0s9MTyM4TaOwVOmhwRckDqMfxrbsKVfm@mail.gmail.com>
On Jan 27, 2011, at 12:53 PM, Ævar Arnfjörð Bjarmason wrote:
> You'll be much better off if you have project-specific repositories.
But how often do you have a project that has no external or internal dependencies on any other packages or libraries? Any project I've ever done, big or small, has relied on some existing codebase. Imagine a project that uses liba and libb, which both reference libc. To use Git, I'd have to have copies of libc existing in three repositories, and copies of liba and lib in two repositories each. What a nightmare... and that's only a trivial hypothetical example.
I understand that Git was designed with a specific feature set in mind -- to manage Linux kernel development -- and as such isn't going to satisfy everyone. But I'm having trouble figuring out how to integrate it as the SCM in my projects, which aren't organized any differently than any other projects I've seen. Surely I can't be the only person with these difficulties? Git just doesn't seem to scale when it comes to componentized projects. Do other distributed VCSs work better than Git in this respect?
I'm really trying to get on the Git bandwagon, here.
--
Thomas Hauk
Shaggy Frog Software
www.shaggyfrog.com
^ permalink raw reply
* Re: help understanding git diff output
From: Eugene Sajine @ 2011-01-27 23:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4hqgd71.fsf@alter.siamese.dyndns.org>
On Thu, Jan 27, 2011 at 6:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eugene Sajine <euguess@gmail.com> writes:
>
>> I get empty diff when i execute:
>>
>> $git diff branch1..branch2
>>
>> and i also get empty diff when running
>>
>> $git diff branch2..branch1
>
> The thing is, "diff" is about comparing "two endpoints".
>
> We still do support, as a backward compatibility measure, the A..B
> notation to help people who learned "git diff" from ancient documents, and
> we don't plan to deprecate the notation in any way, but don't be fooled by
> the notation which usually means "the range from A to B". In the context
> of diff, it does not mean a range, as diff is about two "endpoints".
>
>> What i cannot wrap my mind around is why the command below with
>> symmetric difference range gives me non-empty diff
>>
>> $git diff branch1...branch2
>
> "git diff A...B" is a short-hand for "git diff $(git merge-base A B) B",
> naming the fork point between branches A and B as one end, and B as the
> other end, of the diff. Again, diff is about two "endpoints", and the
> notation does not mean a symmetric difference range.
>
>
>
Thanks a lot, Junio. I was looking at the wrong place in the
documentation. Skipped the part in diff doc explaining that range
notations are not exactly ranges for diff.
Thanks,
Eugene
^ permalink raw reply
* Re: help understanding git diff output
From: Junio C Hamano @ 2011-01-27 23:05 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <AANLkTi=H1LuGfQC8+u83So+6XyOqJxHJ3zsdgs4JTdkc@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> I get empty diff when i execute:
>
> $git diff branch1..branch2
>
> and i also get empty diff when running
>
> $git diff branch2..branch1
The thing is, "diff" is about comparing "two endpoints".
We still do support, as a backward compatibility measure, the A..B
notation to help people who learned "git diff" from ancient documents, and
we don't plan to deprecate the notation in any way, but don't be fooled by
the notation which usually means "the range from A to B". In the context
of diff, it does not mean a range, as diff is about two "endpoints".
> What i cannot wrap my mind around is why the command below with
> symmetric difference range gives me non-empty diff
>
> $git diff branch1...branch2
"git diff A...B" is a short-hand for "git diff $(git merge-base A B) B",
naming the fork point between branches A and B as one end, and B as the
other end, of the diff. Again, diff is about two "endpoints", and the
notation does not mean a symmetric difference range.
^ permalink raw reply
* Re: [PATCH v3] Sanity-check config variable names
From: Junio C Hamano @ 2011-01-27 22:45 UTC (permalink / raw)
To: Libor Pechacek; +Cc: git, Jeff King
In-Reply-To: <20110127142815.GC6312@fm.suse.cz>
Libor Pechacek <lpechacek@suse.cz> writes:
> Sanity-check config variable names when adding and retrieving them. As a side
> effect code duplication between git_config_set_multivar and get_value (in
> builtin/config.c) was removed and the common functionality was placed in
> git_config_parse_key.
>
> This breaks a test in t1300 which used invalid section-less keys in the tests
> for "git -c". However, allowing such names there was useless, since there was
> no way to set them via config file, and no part of git actually tried to use
> section-less keys. This patch updates the test to use more realistic examples.
>
> Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
> Cc: Jeff King <peff@peff.net>
> ---
>
> On Fri 21-01-11 11:23:19, Jeff King wrote:
>> Typo: s/ckeck/check/
>>
>> Other than that, this version looks good to me.
>
> Fixed the typo and return values from get_value and git_config_set_multivar.
> We have changed git_config_parse_key to return negative values on error, but
> forgot to negate the numbers when returning them as exit codes.
Earlier get_value() returned:
-1: when it saw an uncompilable regexp (either in key or value);
0: when a value was available (under --all) or unique (without --all);
1: when the requested variable is missing; and
2: when the requested variable is multivalued under --all.
As the new error condition you are adding is to detect and signal a broken
input, doesn't it fall into the same category as "broken regexp", which in
turn would mean that it should return the same -1?
Or to distinguish between "invalid character in the key" and "no section
name in the key", you might want to add -2 to the mix, but personally I
don't think it is worth it. The advantage of being able to tell between
the two kinds of breakage feels much smaller than the cost of having to
worry about breaking existing callers that try to catch broken user input
by checking the return value from get_value() explicitly against -1, not
just any negative value.
Note that I am not suggesting to change the return value from
config-parse-key in the above; I am only talking about get_value().
> if (use_key_regexp) {
> + char *tl;
> +
> + /* TODO - this naive pattern lowercasing obviously does not
> + * work for more complex patterns like `^[^.]*Foo.*bar' */
> + for (tl = key+strlen(key)-1; tl >= key && *tl != '.'; --tl)
> + *tl = tolower(*tl);
> + for (tl = key; *tl && *tl != '.'; ++tl)
> + *tl = tolower(*tl);
When moving an existing code segment around like this, I would not mind to
see style fixes thrown in to the patch, as long as the moved code is small
enough. Perhaps like this:
/*
* NEEDSWORK: this naive pattern lowercasing obviously does
* not work for more complex patterns like "^[^.]*Foo.*bar".
* Perhaps we should deprecate this altogether someday.
*/
for (tl = key + strlen(key) - 1;
tl >= key && *tl != '.';
tl--)
*tl = tolower(*tl);
for (tl = key; *tl && *tl != '.'; tl++)
*tl = tolower(*tl);
The style rules applied above are...
- We want to see SP around binary operators;
- However, we don't want to see a line that is too long;
- When there is no reason to choose between (pre/post)-(in/de)crement,
post-(in/de)crement is easier to read.
> diff --git a/config.c b/config.c
> index 625e051..c976544 100644
> --- a/config.c
> +++ b/config.c
> @@ -1098,6 +1098,72 @@ int git_config_set(const char *key, const char *value)
> return git_config_set_multivar(key, value, NULL, 0);
> }
>
> +/* Auxiliary function to sanity-check and split the key into the section
/*
* Style. We write our multi-line comments
* like this.
*/
> +int git_config_parse_key(const char *key, char **store_key, int *baselen_)
> +{
> + int i, dot, baselen;
> + const char *last_dot = strrchr(key, '.');
> +
> + /*
> + * Since "key" actually contains the section name and the real
> + * key name separated by a dot, we have to know where the dot is.
> + */
> +
> + if (last_dot == NULL) {
> + error("key does not contain a section: %s", key);
> + return -2;
> + }
> +
> + baselen = last_dot - key;
> + if (baselen_)
> + *baselen_ = baselen;
> +
> + /*
> + * Validate the key and while at it, lower case it for matching.
> + */
> + if (store_key)
> + *store_key = xmalloc(strlen(key) + 1);
Does it make sense for this function to be prepared to get called with
NULL in store_key like this (and in the remainder of your patch)?
The primary reason somebody calls this function is so that the caller can
then use the resulting lowercased form for matching, but "if store-key is
not NULL" feels as if this code is optimized for a special case caller
that only wants to validate without using the resulting lowercased key for
matching, which does not exist yet.
> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index d0e5546..3e79c37 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -876,11 +876,10 @@ test_expect_success 'check split_cmdline return' "
> "
>
> test_expect_success 'git -c "key=value" support' '
> - test "z$(git -c name=value config name)" = zvalue &&
> test "z$(git -c core.name=value config core.name)" = zvalue &&
> - test "z$(git -c CamelCase=value config camelcase)" = zvalue &&
> - test "z$(git -c flag config --bool flag)" = ztrue &&
> - test_must_fail git -c core.name=value config name
> + test "z$(git -c foo.CamelCase=value config foo.camelcase)" = zvalue &&
> + test "z$(git -c foo.flag config --bool foo.flag)" = ztrue &&
> + test_must_fail git -c name=value config core.name
> '
Don't you want to make sure that your sanity check triggers in new tests?
^ permalink raw reply
* help understanding git diff output
From: Eugene Sajine @ 2011-01-27 22:11 UTC (permalink / raw)
To: git
Hi,
Could you please help understanding the output of git diff.
I have two branches with this type or relationship:
0-a-b-c-d-e-f-g (branch1)
\a1-a2-a3-b-c-d1-d2-e-f1-f2-g (branch2)
Where commits a1,a2 and a3 as well as other numbered commits in
branch2 are the split version of their counterparts in branch1.
The the branch2 was created by creating the branch2 from branch one
and rebased on 0 with few commits being cplit up during the rebase.
I.e. the resulting state is the same for both branches.
I get empty diff when i execute:
$git diff branch1..branch2
and i also get empty diff when running
$git diff branch2..branch1
What i cannot wrap my mind around is why the command below with
symmetric difference range gives me non-empty diff
$git diff branch1...branch2
Please, advise
Thanks a lot,
Eugene
^ permalink raw reply
* Re: Project- vs. Package-Level Branching in Git
From: Ævar Arnfjörð Bjarmason @ 2011-01-27 20:53 UTC (permalink / raw)
To: Thomas Hauk; +Cc: git
In-Reply-To: <14F4737F-E8E4-4E4E-A625-16CA63CF9EFF@shaggyfrog.com>
On Thu, Jan 27, 2011 at 20:38, Thomas Hauk <tom@shaggyfrog.com> wrote:
> Am I incorrect or is there a way to accomplish with Git what I was
> doing before with P4 and SVN?
Different systems have different methodologies. Perforce and
Subversion are more of a virtual filesystem, while Git tries to track
a single project.
You'll be much better off if you have project-specific repositories.
^ permalink raw reply
* Re: [PATCH v4] fast-import: treat filemodify with empty tree as delete
From: Peter Baumann @ 2011-01-27 20:48 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Sverre Rabbelier, Git Mailing List,
Ramkumar Ramachandra, Shawn O. Pearce, David Barr
In-Reply-To: <20110127204649.GB19378@m62s10.vlinux.de>
On Thu, Jan 27, 2011 at 09:46:50PM +0100, Peter Baumann wrote:
> On Thu, Jan 27, 2011 at 01:48:45PM -0600, Jonathan Nieder wrote:
> > Peter Baumann wrote:
> > > On Thu, Jan 27, 2011 at 12:07:49AM -0600, Jonathan Nieder wrote:
> >
> > >> +++ b/t/t9300-fast-import.sh
> > >> @@ -818,6 +818,48 @@ test_expect_success \
> > >> compare_diff_raw expect actual'
> > >>
> > >> +test_expect_success \
> > >> + 'N: delete directory by copying' \
> > >> + 'cat >expect <<-\EOF &&
> > >> + OBJID
> > >> + :100644 000000 OBJID OBJID D foo/bar/qux
> > >> + OBJID
> > >> + :000000 100644 OBJID OBJID A foo/bar/baz
> > >> + :000000 100644 OBJID OBJID A foo/bar/qux
> > >> + EOF
> > >> + empty_tree=$(git mktree </dev/null) &&
> > >
> > > [ Feel free to ignore me ... ]
> > >
> > > Just a (stupid?) suggestion: Why not put a $EMPTY_TREE definiton in test-lib.sh
> > > (or any other global file sourced in the tests) so if another caller needs this
> > > definition it won't waste cpu cycles doing the calculation via mktree < /dev/null
> > > again?
> >
> > Might be a good idea. Note, though, that that would mean more cpu
> > cycles used rather than less, unless we hardcode the object name
> > (which I prefer not to do).
> >
>
> Wny not? It *is* already hardcoded in the GIT source code (see grep -a1 cache.h
^
EMPTY
> output).
>
> > One possibility would be a lib-object-names.sh defining EMPTY_BLOB and
> > EMPTY_TREE to be sourced by tests that need it.
>
> Hm. Might be a possibility, but if this file only contains 2 hardcoded variables
> I would prefer putting it into test-list.sh instead of an extra file.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v4] fast-import: treat filemodify with empty tree as delete
From: Peter Baumann @ 2011-01-27 20:46 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Sverre Rabbelier, Git Mailing List,
Ramkumar Ramachandra, Shawn O. Pearce, David Barr
In-Reply-To: <20110127194844.GA20894@burratino>
On Thu, Jan 27, 2011 at 01:48:45PM -0600, Jonathan Nieder wrote:
> Peter Baumann wrote:
> > On Thu, Jan 27, 2011 at 12:07:49AM -0600, Jonathan Nieder wrote:
>
> >> +++ b/t/t9300-fast-import.sh
> >> @@ -818,6 +818,48 @@ test_expect_success \
> >> compare_diff_raw expect actual'
> >>
> >> +test_expect_success \
> >> + 'N: delete directory by copying' \
> >> + 'cat >expect <<-\EOF &&
> >> + OBJID
> >> + :100644 000000 OBJID OBJID D foo/bar/qux
> >> + OBJID
> >> + :000000 100644 OBJID OBJID A foo/bar/baz
> >> + :000000 100644 OBJID OBJID A foo/bar/qux
> >> + EOF
> >> + empty_tree=$(git mktree </dev/null) &&
> >
> > [ Feel free to ignore me ... ]
> >
> > Just a (stupid?) suggestion: Why not put a $EMPTY_TREE definiton in test-lib.sh
> > (or any other global file sourced in the tests) so if another caller needs this
> > definition it won't waste cpu cycles doing the calculation via mktree < /dev/null
> > again?
>
> Might be a good idea. Note, though, that that would mean more cpu
> cycles used rather than less, unless we hardcode the object name
> (which I prefer not to do).
>
Wny not? It *is* already hardcoded in the GIT source code (see grep -a1 cache.h
output).
> One possibility would be a lib-object-names.sh defining EMPTY_BLOB and
> EMPTY_TREE to be sourced by tests that need it.
Hm. Might be a possibility, but if this file only contains 2 hardcoded variables
I would prefer putting it into test-list.sh instead of an extra file.
^ permalink raw reply
* Re: Project- vs. Package-Level Branching in Git
From: Andreas Ericsson @ 2011-01-27 20:09 UTC (permalink / raw)
To: Thomas Hauk; +Cc: git
In-Reply-To: <14F4737F-E8E4-4E4E-A625-16CA63CF9EFF@shaggyfrog.com>
On 01/27/2011 08:38 PM, Thomas Hauk wrote:
> Back when I worked at a large games company, we used Perforce, and
> our repo structure looked a little something like this:
>
> /branches /alpha /beta /mainline /packages /external /foolib /1.0
> /1.1 /2.0 /internal /barlib /dev /1.0 /2.0 /bazlib /2.34 /2.35 /qux
> /dev
>
> At the package level, we would split up packages/libraries into two
> groups based on if they were developed at the company or not
> (external/internal), and inside each one, we might have multiple
> versions. In the example above, the repo is for the "qux" game, which
> uses an internal "bazlib" library developed by another group, and the
> "barlib" library which was developed for use on "qux" and may be used
> simultaneously on other projects.
>
> Project-level branches took mainline as a base and branched into the
> /branches directory. Package-level branches would usually take the
> "dev" version (which represented the current development version,
> akin to "master" in Git) as a base and branch into the same parent
> directory but with an actual version name.
>
> I've successfully used this repo structure with several other
> projects over the years at other companies (who were mostly using
> Subversion). Now I'm trying to get into the Git swing of things, but
> it seems to be that Git only offers project-level branching, and
> doesn't allow for the kind of package-level branching I'm describing
> here.
>
> Am I incorrect or is there a way to accomplish with Git what I was
> doing before with P4 and SVN?
>
You're correct. There's no way to accomplish what you wish to do
inside git. I'd suggest submodules, but that still doesn't get
you the per-directory branching inside a git repository, even
though it does make it rather trivial to change versions at will.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH v4] fast-import: treat filemodify with empty tree as delete
From: Jonathan Nieder @ 2011-01-27 19:48 UTC (permalink / raw)
To: Peter Baumann
Cc: Junio C Hamano, Sverre Rabbelier, Git Mailing List,
Ramkumar Ramachandra, Shawn O. Pearce, David Barr
In-Reply-To: <20110127193353.GA19378@m62s10.vlinux.de>
Peter Baumann wrote:
> On Thu, Jan 27, 2011 at 12:07:49AM -0600, Jonathan Nieder wrote:
>> +++ b/t/t9300-fast-import.sh
>> @@ -818,6 +818,48 @@ test_expect_success \
>> compare_diff_raw expect actual'
>>
>> +test_expect_success \
>> + 'N: delete directory by copying' \
>> + 'cat >expect <<-\EOF &&
>> + OBJID
>> + :100644 000000 OBJID OBJID D foo/bar/qux
>> + OBJID
>> + :000000 100644 OBJID OBJID A foo/bar/baz
>> + :000000 100644 OBJID OBJID A foo/bar/qux
>> + EOF
>> + empty_tree=$(git mktree </dev/null) &&
>
> [ Feel free to ignore me ... ]
>
> Just a (stupid?) suggestion: Why not put a $EMPTY_TREE definiton in test-lib.sh
> (or any other global file sourced in the tests) so if another caller needs this
> definition it won't waste cpu cycles doing the calculation via mktree < /dev/null
> again?
Might be a good idea. Note, though, that that would mean more cpu
cycles used rather than less, unless we hardcode the object name
(which I prefer not to do).
One possibility would be a lib-object-names.sh defining EMPTY_BLOB and
EMPTY_TREE to be sourced by tests that need it.
^ permalink raw reply
* Project- vs. Package-Level Branching in Git
From: Thomas Hauk @ 2011-01-27 19:38 UTC (permalink / raw)
To: git
Back when I worked at a large games company, we used Perforce, and our repo structure looked a little something like this:
/branches
/alpha
/beta
/mainline
/packages
/external
/foolib
/1.0
/1.1
/2.0
/internal
/barlib
/dev
/1.0
/2.0
/bazlib
/2.34
/2.35
/qux
/dev
At the package level, we would split up packages/libraries into two groups based on if they were developed at the company or not (external/internal), and inside each one, we might have multiple versions. In the example above, the repo is for the "qux" game, which uses an internal "bazlib" library developed by another group, and the "barlib" library which was developed for use on "qux" and may be used simultaneously on other projects.
Project-level branches took mainline as a base and branched into the /branches directory. Package-level branches would usually take the "dev" version (which represented the current development version, akin to "master" in Git) as a base and branch into the same parent directory but with an actual version name.
I've successfully used this repo structure with several other projects over the years at other companies (who were mostly using Subversion). Now I'm trying to get into the Git swing of things, but it seems to be that Git only offers project-level branching, and doesn't allow for the kind of package-level branching I'm describing here.
Am I incorrect or is there a way to accomplish with Git what I was doing before with P4 and SVN?
--
Thomas Hauk
Shaggy Frog Software
www.shaggyfrog.com
^ 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