* Re: Importing diffs
From: Greg KH @ 2006-01-30 19:57 UTC (permalink / raw)
To: Ian Molton; +Cc: git
In-Reply-To: <43DE1DB7.20909@f2s.com>
On Mon, Jan 30, 2006 at 02:07:51PM +0000, Ian Molton wrote:
> Hi.
>
> is there any reason why git insists diffs be -p1 format ?
Because that's the default for what the Linux kernel project uses? :)
> it makes it hard to import a diff generated by svn (-p0).
I'm pretty sure that svn can output -p1 patches, I've done it in the
past...
thanks,
greg k-h
^ permalink raw reply
* [PATCH] Set errno to EEXIST if mkdir returns EACCES or EPERM
From: Alex Riesen @ 2006-01-30 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
... and the directory already exists. I.E. Cygwin is such
a case: mkdir fail for mounts which reference directly
to windows mounts ("drives").
---
The discussion, which ended up with this patch can be read
here: http://www.cygwin.com/ml/cygwin/2006-01/msg01276.html
BTW, there is this:
http://www.cygwin.com/ml/cygwin/2006-01/msg01380.html
So this patch will probably be not needed soon.
Still I post it just for reference, or in case someone
can't afford an upgrade.
Makefile | 8 ++++++++
checkout-index.c | 2 +-
compat/mkdir.c | 23 +++++++++++++++++++++++
git-compat-util.h | 6 ++++++
4 files changed, 38 insertions(+), 1 deletions(-)
create mode 100644 compat/mkdir.c
c9f480f5d1e777cc0f4861e94c2449bd8c7cf73a
diff --git a/Makefile b/Makefile
index 2e95353..596c2d8 100644
--- a/Makefile
+++ b/Makefile
@@ -66,6 +66,9 @@ all:
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-cache perspective.
+# Define FIX_MKDIR_ERRNO if your mkdir(2) does not always set errno to EEXIST
+# if it failed because of existing directory (notably Cygwin).
+
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
@@ -249,6 +252,7 @@ ifeq ($(uname_O),Cygwin)
# Try uncommenting this if you see things break -- YMMV.
# NO_MMAP = YesPlease
NO_IPV6 = YesPlease
+ FIX_MKDIR_ERRNO = YesPlease
X = .exe
endif
ifeq ($(uname_S),OpenBSD)
@@ -392,6 +396,10 @@ else
endif
endif
endif
+ifdef FIX_MKDIR_ERRNO
+ COMPAT_CFLAGS += -DFIX_MKDIR_ERRNO
+ COMPAT_OBJS += compat/mkdir.o
+endif
ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER)) $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
diff --git a/checkout-index.c b/checkout-index.c
index 53dd8cb..c5a6d6e 100644
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -199,6 +199,6 @@ int main(int argc, char **argv)
if (0 <= newfd &&
(write_cache(newfd, active_cache, active_nr) ||
commit_index_file(&cache_file)))
- die("Unable to write new cachefile");
+ die("Unable to write new cachefile: %s", strerror(errno));
return 0;
}
diff --git a/compat/mkdir.c b/compat/mkdir.c
new file mode 100644
index 0000000..1c2260c
--- /dev/null
+++ b/compat/mkdir.c
@@ -0,0 +1,23 @@
+#include <unistd.h>
+#include <errno.h>
+#include <sys/stat.h>
+#include "../git-compat-util.h"
+#undef mkdir
+
+int gitmkdir(const char *dir, mode_t mode)
+{
+ int rc = mkdir(dir, mode);
+ if ( rc < 0 ) {
+ int e = errno;
+ if ( EACCES == e || EPERM == e )
+ {
+ struct stat st;
+ if ( stat(dir, &st) == 0 )
+ errno = EEXIST;
+ else
+ errno = e;
+ }
+ }
+ return rc;
+}
+
diff --git a/git-compat-util.h b/git-compat-util.h
index f982b8e..9cf3aab 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -154,4 +154,10 @@ static inline int sane_case(int x, int h
#ifndef MAXPATHLEN
#define MAXPATHLEN 256
#endif
+
+#ifdef FIX_MKDIR_ERRNO
+#define mkdir gitmkdir
+int gitmkdir(const char *dir, mode_t mode);
+#endif
+
#endif
--
1.1.4.g7397-dirty
^ permalink raw reply related
* Re: [RFC] shallow clone
From: Junio C Hamano @ 2006-01-30 19:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0601301305100.20228@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > - disallow fetching from this repo, and
>>
>> Why? It's perfectly acceptable to pull from an incomplete
>> repo, as long as you don't care about the old history.
>
> Right. But should that be the default? I don't think so. Therefore:
> disable it, and if the user is absolutely sure to do dumb things, she'll
> have to enable it explicitely.
If the downstream person wants to have a shallow history of post
X.org X server core to further hack on it, I do not think of a
reason why we would want to refuse her from cloning a repository
of a fellow developer who has already done such a shallow copy.
If such a clone is done without telling the downstream that the
result is a shallow one, it is "dumb". I would agree it should
not be done. We need to propagate the grafts to the downstream
when a clone is done because of this.
By the way, please refrain from discussing .git/config vs
.git/eparate-config-files issue in this thread. My personal
feeling so far is that the information current graft represents
is good enough to support shallow clones, and if not we can
extend its semantics to support such. It can be discussed
independently if it is a good idea to move the final result
(grafts with updated semantics) to config file. Even if we end
up not doing any of the shallow cloning support we have been
discussing, moving the information in .git/info/grafts to config
might make sense. The issue is tangential.
^ permalink raw reply
* Re: [RFC] shallow clone
From: Junio C Hamano @ 2006-01-30 19:25 UTC (permalink / raw)
To: Simon Richter; +Cc: git
In-Reply-To: <43DDFF5C.30803@hogyros.de>
Simon Richter <Simon.Richter@hogyros.de> writes:
>> - disallow fetching from this repo, and
>
> Why? It's perfectly acceptable to pull from an incomplete repo, as
> long as you don't care about the old history.
I agree. As long as the cloned one can record itself as a
shallow one (and with what epochs), I do not see a reason to
forbid second generation clone from a shallow repository.
> Hrm, I think there should also be a way to shrink a repo and "forget"
> old history occasionally (obviously, use of that feature would be
> highly discouraged).
I do not think of a reason to discourage it, and I think you can
do the "forgetting" part with the current set of tools. Choose
appropriate cauterizing points, set up info/grafts and running
"repack -a -d" would be sufficient.
> IMO, it may be a lot more robust to just have a list of "cutoff"
> object ids in .git/shallow instead of messing with grafts here, as
> adding or removing a line from that file is an easier thing to do for
> porcelain (or by hand) than rewriting the grafts file. Whether that
> list would be inclusive or exclusive would need to be decided still.
I would rather not to have .git/shallow nor .git/shallow_start.
Cauterizing is not any more special than other grafts entries.
If you have grafted historical kernel repository behind the
official kernel repository with 2.6.12-rc2 epoch, I do not think
of any reason to forbid people from cloning such with the
grafts.
^ permalink raw reply
* Re: git vs git
From: Junio C Hamano @ 2006-01-30 19:22 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20060130172344.GA20867@harddisk-recovery.com>
Erik Mouw <erik@harddisk-recovery.com> writes:
> Hey, I said "untested" :) But yeah, you're right. Your syntax is
> correct, every time I write such a wrapper I try to remember it...
I would tolerate if you say it apologetically, but let all of us
try to refrain from sending something marked *proudly* as
"untested".
That is a privilege reserved for only a few ;-) Currently only
one -- Linus.
^ permalink raw reply
* Re: merging question
From: Peter Eriksen @ 2006-01-30 19:14 UTC (permalink / raw)
To: git
In-Reply-To: <43DE3D73.60904@f2s.com>
On Mon, Jan 30, 2006 at 04:23:15PM +0000, Ian Molton wrote:
> Is it possible to merge all the changes up to a specific tagged version
> of another branch ?
>
> I'd like to pull all the changes up to 2.6.15 into a branch created from
> 2.6.12, which has been subsequently modified. I dont yet want to pull
> later changes in.
This is what I tried to do, and it seems to work:
git checkout -b mywork v2.6.12
# work, work, work
git commit -a
git merge "Merging happily." mywork v2.6.15
The man pages can explain it better than I can.
> on a side note, how does one pull in an individual changeset, rather
> than the head of an entire branch ?
Look into git-cherry and git-cherry-pick.
Regards,
Peter
^ permalink raw reply
* Re: [Census] So who uses git?
From: Carl Baldwin @ 2006-01-30 18:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Keith Packard, Martin Langhoff, Linus Torvalds, Git Mailing List
In-Reply-To: <7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net>
Junio,
You don't seem to give git enough credit. I am a hardware engineer with
many softwareish responsibilities. One of those is to keep up to date
with the many commercial and free SCM type tools that are available.
Git has become my SCM tool of choice for many reasons.
- Anyone can install and fire it up without license/contract hassles.
- The infrastructure barriers to getting a project started with git are
about as low as they can be.
- Geographically distributed teams even inside a corporation are
becoming more common. Git's repository design meets this need
perfectly.
- The repository is also to designed to be inherently safe from
data-loss and corruption even in the face of concurrent writes due to
each objects' immutable nature.
- While on the subject of the repository. Good job keeping it simple.
I was able to learn pretty much all there is to know from a technical
stand-point about the objects and refs directories in an afternoon.
It follows a principle I always work toward myself. "Make it simple
enough that there are obviously no difficiencies rather than making it
complicated so that there are no obvious difficiencies."
- In my opinion git is flexible enough to support just about any
development/build/release flow that one can think of. Most of the
free tools (including subversion and arch) make branching and merging
--- on which most of these flows rely --- way too heavy-weight. Git
shows how light-weight it can be.
Not only can parallel development happen easily between
users/repositories but parallel development is trivial even within the
same repository. I think your 'pu' system illustrates how powerful
it can be. I myself have had up to four concurrent branches where I
implemented four different features in parallel in the same repository
easily switching between them. It was almost too easy to bring them
together using merge as each one finished.
I was just reading through an article on how to choose an SCM last
week and I kept thinking how git could be used to meet almost every
one (if not all) of the needs discussed.
- Git supports enough network protocols to make it immediately useful in
about any situation with firewalls and such. This is where it leaves
monotone behind.
The biggest hurdle that I've seen in adopting git is training the users.
I myself took to it like a duck to water but I've found that even some
of my brightest colleages have trouble wrapping their heads around it.
Currently, I'm trying to look at what parts they are having the most
trouble with. In general, I think it is grasping the reason for the
index file and how git commands like git-commit and git-diff interact
with it.
Even so, I've always appreciated those tools that may have a steeper
learning curve but that pay dividends over time. Also, I should mention
that this learning curve has been flattening over time as git has
developed and obtained more porcelainish commands.
Carl
On Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:
> Keith Packard <keithp@keithp.com> writes:
>
> Wow....... You are switching Cairo and X.org from CVS to git?
>
> It could be that anything is better than CVS these days, but I
> have to admit that my jaw dropped after reading this, primarily
> because I've have never touched anything as big as X.
>
> Awestruck, dumbstruck,... Xstruck. Yeah, I know I should have
> more faith in git. Earlier I heard Wine folks are running git
> in parallel with CVS as their dual primary SCM now, and of
> course git is the primary SCM for the Linux kernel project.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin RADCAD (R&D CAD)
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* (unknown)
From: Mark Wooding @ 2006-01-30 18:50 UTC (permalink / raw)
To: git
git-http-fetch seems buggy. I /think/ it's getting confused by a
combination of a large top-level tree (lots of blobs directly attached)
attached to the top commit, together with most of the things being
packed.
To illustrate the bug, create a repository with the following shell
script. (It will create a working tree called `funt' with a little GIT
history inside.)
----
#! /bin/sh
set -e
mkdir funt
cd funt
git-init-db
yes | nl | head -200 | while read n hunoz; do echo file $n >foo.$n; done
git-add *
echo Boo. | git-commit -F - -a
git-repack
git-prune-packed
echo Censored >foo.197
echo Ouch. | git-commit -F - -a
git-update-server-info
----
Then put the repository somewhere your web server will let you get to
it, and try to clone it, say using
git-clone http://boyle.nsict.org/~mdw/funt.git
(Yes, that repository exists and is live; the server is fairly
well-connected.) You ought to be greeted with text like this:
error: Unable to find b4f495485ca9ae825ec8c504cdcf24652342f43c under
http://boyle.nsict.org/~mdw/funt/.git/
Cannot obtain needed commit b4f495485ca9ae825ec8c504cdcf24652342f43c
while processing commit 351c72525b9ee5b2321c65598ce82a4e79015012.
If you're very lucky, git-http-fetch will segfault.
What's going on here?
Think about the repository layout for a bit. There's a `big' pack file,
and a little commit. The commit has an unpacked tree attached, but
almost all of its leaves are in the pack. The commit's parent is
packed.
So git-http-fetch starts by filling its queue with prefetches for blob
objects which are packed (and so it gets 404s for them). This is fine.
However! when it comes to collect the parent commit, it realises it
needs to fetch the pack list. Unfortunately, something goes wrong in
run_active_slot. As far as I can make out, the slot used to collect
.../info/packs is being /reused/ by fill_active_slots (called by
step_active_slots) before fetch_indices is returned to. Since the
prefetch which got the new slot is for an object which got packed, it
fails with a 404, which is written back to the slot. The result is that
fetch_indices thinks that the pack list doesn't exist (even though it
actually does, and libcurl fetched it just fine, thanks). This is
marked as a permanent error, and that parent commit can't be found.
The segfault is I think due to this reuse too, but it only happens
sometimes and I'm not entirely clear on why.
I'm afraid I don't have a patch. I've spent a little while trying to
fix this bug myself, but my changes just seem to cause wedging, or fd
leaks, or segfaults, or all three, so it's obvious I don't understand
the code well enough.
-- [mdw]
^ permalink raw reply
* Re: [RFC] shallow clone
From: Junio C Hamano @ 2006-01-30 18:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0601301220420.6424@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> . Download the full tree for v2.6.14 commit and store its
>> objects locally.
>
> On first read, I mistook "tree" for "commit"...
It turns out that this 'single' request step is unneeded, as
long as we implement 'graft' requests. We can then tell
"Cauterize at v2.6.14 and give me the master" to `upload-pack`.
`upload-pack` would run `rev-list --objects master`, tries to include
everything that is reachable from "master", but notices that the
v2.6.14 commit does not have any parent (thanks to the
customized graft) and stops there -- the result is the history
since v2.6.14.
>> . Set up `info/grafts` to lie to the local git that Linux kernel
>> history began at v2.6.14 version.
>
> Maybe also record this in .git/config, so that you can
>
> - disallow fetching from this repo, and
> - easily extend the shallow copy to a larger shallow one, or a full one.
I thought about that before I wrote the message, but it boils
down to grepping lines from grafts that have only one object
name (i.e. cauterizing records), so it is redundant.
Also there is no strict reason to forbid cloning from such a
shallow repository. No harm is done as long as you make it
clear to somebody who clones from you that what you have is a
shallow copy, so that the cloned repository can cauterize
history at appropriate places.
A second generation clone, when cloning from a shallow
repository, needs to mark itself that it has the same or
shallower history (otherwise a third generation clone from it
would not work), so the `upload-pack` protocol needs to be
updated to send grafts information the `upload-pack` side
usually uses to the downloader even when 'graft' request is not
used by the downloader. But once it is done, you should be able
to clone safely from a shallow repository and end up with a
repository with the same (or shallower -- if you asked to make a
shallow clone from it) history.
> Why not just start another fetch? Then, "have <refs/tags/start_shallow>"
> would be sent, and upload-pack does the right thing?
Yes, almost. We need to realize that `upload-pack` that hears
"have A, want B" is allowed to omit objects that appear in
`ls-tree B` output but not in `ls-tree A`. "have A" means not
just "I have A", but "I have A and all of its ancestors", so
just sending "have start_shallow" (or start_shallow^ for that
matter) is not quite enough [*1*].
> If you absolutely want to get only one pack, which then is stored as-is,
> upload-pack could start two rev-list processes: one for the tree and one
> for all the rest.
The message you are responding did two separate transfers (one
'single', and another 'fetch'); I do not particularly mind doing
two (it is just an initial clone anyway), but as I said it turns
out that we do not need the initial 'single'.
>> [NOTE]
>> Most likely this is not directly run by the user but is run as
>> the first command invoked by the shallow clone script.
>
> Better make it an option to git-clone
Probably -- I was just outlining the lowest-level mechanism and
haven't thought much about the UI.
[Footnote]
*1* This is true even without more aggressive optimization by
rev-list that does not exist there yet. Here is a minimalistic
demonstration. One file project with a handful straight-line
commits. Each change to the file reverts the change made by the
previous commit.
* The HEAD commit has "white", the HEAD~1 "black" and HEAD~2
"white".
* We say we are interested in things since HEAD~2 (i.e. we
pretend that the history starts at HEAD~1 and it does not
have a parent) and ask for HEAD.
* Notice that only one copy of the file appears in the output.
It is "black" blob. We do not get "white" blob because we
are telling it that we _have_ HEAD~2. The resulting set of
objects is not enough to check-out the HEAD commit.
This roughly corresponds to your "have shallow_start", but not
quite -- in that sequence you have objects for HEAD~2 commit.
But the point is that I want to leave the door open for
optimizing upload-pack, so that it can choose to omit objects
that do not appear in A when you say "have A", if the object
appears in one of A's ancestors.
-- >8 --
#!/bin/sh
rm -fr .git
git init-db
zebra=white
echo $zebra >file
git add file
git commit -m initial
for i in 0 1 2 3 4 5
do
case $zebra in
white) zebra=black ;;
black) zebra=white ;;
esac
echo $zebra >file
git commit -a -m "$i $zebra"
done
git rev-list --objects HEAD~2..HEAD |
git name-rev --stdin
^ permalink raw reply
* Re: [PATCH] diff: add --no-diff-deleted to make -p more pleasant
From: Jon Loeliger @ 2006-01-30 18:08 UTC (permalink / raw)
To: Git List
In-Reply-To: <7vy80ykd3j.fsf@assigned-by-dhcp.cox.net>
On Sun, 2006-01-29 at 14:12, Junio C Hamano wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > This is a feature I've stol^Wborrowed from svn that I find very
> > useful since I usually don't care to see what I've deleted.
>
> There is a thing called --diff-filter, and
>
> git diff -p --no-diff-deleted
>
> is equivalent to
>
> git diff -p --diff-filter=AM
>
> when you are not using rename/copy detection (and a byte
> shorter).
Hmmm.... I think this may be the problem:
% grep -r diff-filter Documentation/
Documentation/git-diff.txt:$ git diff --diff-filter=MRC <1>
And that is:
Limiting the diff output::
+
------------
$ git diff --diff-filter=MRC <1>
$ git diff --name-status -r <2>
$ git diff arch/i386 include/asm-i386 <3>
<1> show only modification, rename and copy, but not addition
nor deletion.
<2> show only names and the nature of change, but not actual
diff output. --name-status disables usual patch generation
which in turn also disables recursive behaviour, so without -r
you would only see the directory name if there is a change in a
file in a subdirectory.
<3> limit diff output to named subtrees.
That's pretty thin documentation there.
Unless someone beats me to it, I'll try to find
a spare documentation cycle...
jdl
^ permalink raw reply
* Re: git vs git
From: Erik Mouw @ 2006-01-30 17:23 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Hendrik Visage, david, git
In-Reply-To: <86acddirjr.fsf@blue.stonehenge.com>
On Mon, Jan 30, 2006 at 08:55:36AM -0800, Randal L. Schwartz wrote:
> >>>>> "Erik" == Erik Mouw <erik@harddisk-recovery.com> writes:
>
> Erik> #! /bin/sh
> Erik> # sct: call git
> Erik> gitpath=/path/to/git
> Erik> export PATH=$gitpath:$PATH
> Erik> exec $gitpath/git $*
>
> You must not get a lot of spaces in your pathnames.
That usually doesn't happen in the kernel tree (which is what the OP
wants to follow).
> I think you want
> those last two lines to be:
>
> export PATH="$gitpath:$PATH"
> exec "$gitpath/git" "$@"
>
> Typical lazy shell programmer. :) :)
Hey, I said "untested" :) But yeah, you're right. Your syntax is
correct, every time I write such a wrapper I try to remember it...
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: git vs git
From: Randal L. Schwartz @ 2006-01-30 16:55 UTC (permalink / raw)
To: Erik Mouw; +Cc: Hendrik Visage, david, git
In-Reply-To: <20060130153715.GE30671@harddisk-recovery.com>
>>>>> "Erik" == Erik Mouw <erik@harddisk-recovery.com> writes:
Erik> #! /bin/sh
Erik> # sct: call git
Erik> gitpath=/path/to/git
Erik> export PATH=$gitpath:$PATH
Erik> exec $gitpath/git $*
You must not get a lot of spaces in your pathnames. I think you want
those last two lines to be:
export PATH="$gitpath:$PATH"
exec "$gitpath/git" "$@"
Typical lazy shell programmer. :) :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git vs git
From: Johannes Schindelin @ 2006-01-30 16:26 UTC (permalink / raw)
To: Hendrik Visage; +Cc: Erik Mouw, david, git
In-Reply-To: <d93f04c70601300809v2f18221bxb4ddb495a6f2f47f@mail.gmail.com>
Hi,
On Mon, 30 Jan 2006, Hendrik Visage wrote:
> On 1/30/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
> >
> > Yes, this has been discussed in the past.
>
> Hmm... liked to know the search terms to use :(
"GNU Interactive Tools" ;-)
Ciao,
Dscho
^ permalink raw reply
* merging question
From: Ian Molton @ 2006-01-30 16:23 UTC (permalink / raw)
To: git
Is it possible to merge all the changes up to a specific tagged version
of another branch ?
I'd like to pull all the changes up to 2.6.15 into a branch created from
2.6.12, which has been subsequently modified. I dont yet want to pull
later changes in.
on a side note, how does one pull in an individual changeset, rather
than the head of an entire branch ?
^ permalink raw reply
* Sync repository between NTB and WKS
From: Jiri Netolicky @ 2006-01-30 16:13 UTC (permalink / raw)
To: git
Have a nice day.
Can you advise me what is the best way
to synchronize repositories between
workstation and notebook? Now before I left office,
I synchronize repository between workstation
and notebook(blue-nb) as any other files by rsync:
rsync -avr . blue-nb:work/source/portal
and when I coming into the office
by the same way sync from NTB to WKS. It works
fine but I have not to forget syncing even
if I work on different sources.
Today I try on WKS repository
git-pull ssh://blue-nb/~netolish/work/source/portal
but the new branch I create on NTB during weekend
(and which is actual on NTB) is merged into
actual master branch. I hope that the new branch
will be created on WKS repository. What I am doing
wrong?.
This is my first experiments with git, so sorry for
beginners questions.
Jiri Netolicky aka Netolish
^ permalink raw reply
* Re: git vs git
From: Hendrik Visage @ 2006-01-30 16:09 UTC (permalink / raw)
To: Erik Mouw; +Cc: david, git
In-Reply-To: <20060130153715.GE30671@harddisk-recovery.com>
On 1/30/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
>
> Yes, this has been discussed in the past.
Hmm... liked to know the search terms to use :(
> GNU git development is dead. The last release is from March 13, 2000.
That doesn't mean it's not used extensively :)
> > Could the name git perhaps be reconsideredto something like SCT? or GnuSCT?
>
> I don't think that will happen. The number of source control git users
> outnumbers the number of GNU git users, so consider it a lost case.
Okay, this is the point where the "number of git developers outnumber the number
of GNU git developers" is more correct :(
> > Just asking, as it do cause hassles when an environment is using git
> > and suddenly
> > need to load git to download newer drivers etc. and then git isn't
> > working because the wrong git is in the right place :(
>
> I think we found the only GNU git user in the world! ;-)
You might be surprised, it much nicer IMO than mc
> A simple workaround would be to install git in a directory not in your
> path and put a shell script "sct" in your path that just calls git.
> Something like (untested):
The problem is that the distro people are having troubles deciding how to
make this work and us users are having to suffer this :(
Actually it's at the point where I can't use/install cogito because I
already have GNU git installed, and the name clashes... so I can't do
disecting searches on my AMD64 with problems in a certain device
driver since 2.6.13 :(
--
Hendrik Visage
^ permalink raw reply
* Re: git vs git
From: Erik Mouw @ 2006-01-30 15:37 UTC (permalink / raw)
To: Hendrik Visage; +Cc: david, git
In-Reply-To: <d93f04c70601300714i4b7b3b58qa5aa151e3e42a413@mail.gmail.com>
On Mon, Jan 30, 2006 at 05:14:28PM +0200, Hendrik Visage wrote:
> as few of you might know, there existed a very nice mc/norton commander
> orientated tool called git
> Homepage: http://www.gnu.org/software/git/
> Description: GNU Interactive Tools - increase speed and
> efficiency of most daily task
Yes, this has been discussed in the past.
> This package have been in existence since many summers, but the name choice for
> git - the stupid content tracker, seems to cause several weird problems when
> you don't want/expect it :(
GNU git development is dead. The last release is from March 13, 2000.
> Could the name git perhaps be reconsideredto something like SCT? or GnuSCT?
I don't think that will happen. The number of source control git users
outnumbers the number of GNU git users, so consider it a lost case.
> Just asking, as it do cause hassles when an environment is using git
> and suddenly
> need to load git to download newer drivers etc. and then git isn't
> working because the wrong git is in the right place :(
I think we found the only GNU git user in the world! ;-)
A simple workaround would be to install git in a directory not in your
path and put a shell script "sct" in your path that just calls git.
Something like (untested):
#! /bin/sh
# sct: call git
gitpath=/path/to/git
export PATH=$gitpath:$PATH
exec $gitpath/git $*
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: git vs git
From: Josh Boyer @ 2006-01-30 15:30 UTC (permalink / raw)
To: Hendrik Visage; +Cc: david, git
In-Reply-To: <d93f04c70601300714i4b7b3b58qa5aa151e3e42a413@mail.gmail.com>
On 1/30/06, Hendrik Visage <hvjunk@gmail.com> wrote:
> Hi there,
> as few of you might know, there existed a very nice mc/norton commander
> orientated tool called git
> Homepage: http://www.gnu.org/software/git/
> Description: GNU Interactive Tools - increase speed and
> efficiency of most daily task
IIRC, this was renaming itself to "gitfm". So perhaps you'd like to
ask the maintainer of this tool what the status of that is.
josh
^ permalink raw reply
* Re: [Census] So who uses git?
From: Mike McCormack @ 2006-01-30 15:23 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Dave Jones, Junio C Hamano, Keith Packard, Martin Langhoff,
Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601291438251.25300@iabervon.org>
Daniel Barkalow wrote:
> I think we'll see a lot more adoption when we have a CVS daemon interface
> (so projects can stop having a CVS repository, and support both sorts of
> users with a git repository and have better metadata), and also if someone
> sets up a place for putting git imports of CVS projects, so people will
> know that other people are using git.
The Wine project is using a GIT repository which is mirrored into CVS.
Alexandre wrote scripts to mirror GIT commits into CVS, so developers
can use whichever they're more comfortable with, and the CVS repository
remains up to date.
We've found that patch submitters using GIT tend to send multiple
patches per day, and that those using CVS tend to send a patch or two
occasionally or just keep up to date with the source.
Mike
^ permalink raw reply
* Re: git vs git
From: David Lang @ 2006-01-30 15:18 UTC (permalink / raw)
To: Hendrik Visage; +Cc: david, git
In-Reply-To: <d93f04c70601300714i4b7b3b58qa5aa151e3e42a413@mail.gmail.com>
this debate has taken place many times, please read the archives for the
details.
short answer, no the name will not be changed unless new (as in
different) arguments are made.
David Lang
On Mon, 30 Jan 2006, Hendrik Visage wrote:
> Date: Mon, 30 Jan 2006 17:14:28 +0200
> From: Hendrik Visage <hvjunk@gmail.com>
> To: david@dgreaves.com, git@vger.kernel.org
> Subject: git vs git
>
> Hi there,
> as few of you might know, there existed a very nice mc/norton commander
> orientated tool called git
> Homepage: http://www.gnu.org/software/git/
> Description: GNU Interactive Tools - increase speed and
> efficiency of most daily task
>
> This package have been in existence since many summers, but the name choice for
> git - the stupid content tracker, seems to cause several weird problems when
> you don't want/expect it :(
>
> Could the name git perhaps be reconsideredto something like SCT? or GnuSCT?
>
> Just asking, as it do cause hassles when an environment is using git
> and suddenly
> need to load git to download newer drivers etc. and then git isn't
> working because the wrong git is in the right place :(
>
> Thanx
> --
> Hendrik Visage
> -
> 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
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* git vs git
From: Hendrik Visage @ 2006-01-30 15:14 UTC (permalink / raw)
To: david, git
Hi there,
as few of you might know, there existed a very nice mc/norton commander
orientated tool called git
Homepage: http://www.gnu.org/software/git/
Description: GNU Interactive Tools - increase speed and
efficiency of most daily task
This package have been in existence since many summers, but the name choice for
git - the stupid content tracker, seems to cause several weird problems when
you don't want/expect it :(
Could the name git perhaps be reconsideredto something like SCT? or GnuSCT?
Just asking, as it do cause hassles when an environment is using git
and suddenly
need to load git to download newer drivers etc. and then git isn't
working because the wrong git is in the right place :(
Thanx
--
Hendrik Visage
^ permalink raw reply
* Importing diffs
From: Ian Molton @ 2006-01-30 14:07 UTC (permalink / raw)
To: git
Hi.
is there any reason why git insists diffs be -p1 format ?
it makes it hard to import a diff generated by svn (-p0).
thanks!
^ permalink raw reply
* Re: [RFC] shallow clone
From: Simon Richter @ 2006-01-30 13:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0601301305100.20228@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 3278 bytes --]
Hi,
Johannes Schindelin wrote:
[config as a registry]
> It is becoming sort of a registry: it contains metadata about the current
> repository, easily available to scripts and programs.
Provided you have a parser that can handle it.
> I beg to differ on your personal opinion on the grounds that the
> robustness comes from testing, not from diversity. I much prefer to have a
> well tested config mechanism to having dozens of differently formatted
> files with less-than-well tested parsers.
Indeed. But we already have a method for associating data values with
keys in a hierarchical namespace, and that one is pretty well tested. :-)
>>Why? It's perfectly acceptable to pull from an incomplete repo, as long as you
>>don't care about the old history.
> Right. But should that be the default? I don't think so. Therefore:
> disable it, and if the user is absolutely sure to do dumb things, she'll
> have to enable it explicitely.
What harm is done if I have an incomplete repository? It would probably
make more sense to emit a warning on clone and explain things if the
user tries to go to a version she doesn't have.
>>Hrm, I think there should also be a way to shrink a repo and "forget" old
>>history occasionally (obviously, use of that feature would be highly
>>discouraged).
> Yes. And you need information about how shallow it used to be. My
> suggestion was to store that information at a place specific to that
> repository (see above).
Indeed, but you are keeping this information in two places, namely the
grafts file and the config file. This is asking for trouble if they ever
get out of sync.
>>>How about refs/tags/start_shallow?
>>No, as that would imply that cloning from such a repo is disallowed.
> See above.
Well, I can however see the use case of a developer hosting an
incomplete repo on a free web service and another developer wanting to
merge her changes into her (complete) repo. You would have to
specialcase this tag in the fetch operation to avoid copying it over.
What's probably worse: You can only have a single cutoff point that way.
You probably want multiple in case you want to cut off at a place where
development happened in multiple branches that got subsequently merged
inside the window of objects you keep.
> The functionality of cutoff objects is included in grafts functionality,
> so why should we spend time on reimplementing a subset of features?
I would ask for the grafts parser to add "fake" grafts when it
encounters the "shallow" file. Otherwise, it would be hard to
distinguish between grafts the user made when doing interesting merges,
and grafts that were created to build a shallow repo, because you would
need some heuristics to figure out the latter from the former if you
want to have a function in your porcelain to "pull more/all objects".
> I beg your pardon, you want to edit this information *by hand*? Wow.
Yes. That is actually the reason I like git so much: I can repair it by
hand if something breaks, and this can be done with simple commands. I
can remove an object id from a file with "grep -v" or perl. I would need
to fire up an editor or hack a longer script if I wanted to fix
something inside a complex file that does multiple things.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* how to merge...
From: Ian Molton @ 2006-01-30 12:25 UTC (permalink / raw)
To: git
Hi...
Well, I've got the basics of importing patches from outside git now, so
the next question is...
suppose I've aplpied the 2.6.16-rc1-mm3 patch into its own branch in my
local git repo.
I've also created an arm26 branch from the master 2.6.16-rc1.
I want to pull some patches from the -mm3 branch into the arm26 one, as
a single change.
Obviously, I could simply make a diff including just those files and
apply it to my arm26 branch, but I'd prefer not to if theres a better
way that allows git to keep track of what really happened.
Presumably the 'correct' fix is to import the broken up -mm patchset so
git can pull only the changes relating to those files, but since Im
learning and not everyone provides broken up patchsets, it'd be nice to
know if theres a way to do it 'the hard way'.
Cheers!
^ permalink raw reply
* Re: [RFC] shallow clone
From: Johannes Schindelin @ 2006-01-30 12:13 UTC (permalink / raw)
To: Simon Richter; +Cc: Junio C Hamano, git
In-Reply-To: <43DDFF5C.30803@hogyros.de>
Hi,
On Mon, 30 Jan 2006, Simon Richter wrote:
> Johannes Schindelin wrote:
>
> > > . Set up `info/grafts` to lie to the local git that Linux kernel
> > > history began at v2.6.14 version.
>
> > Maybe also record this in .git/config, so that you can
>
> I like that "config" thing less and less every day. It appears to become a
> kind of registry, where having dedicated files for specific functionality
> would provide the robustness of tools not having to touch things they do not
> care about; but that's just personal opinion.
It is becoming sort of a registry: it contains metadata about the current
repository, easily available to scripts and programs.
I beg to differ on your personal opinion on the grounds that the
robustness comes from testing, not from diversity. I much prefer to have a
well tested config mechanism to having dozens of differently formatted
files with less-than-well tested parsers.
Thank you for the insights in your personal opinion anyway.
> > - disallow fetching from this repo, and
>
> Why? It's perfectly acceptable to pull from an incomplete repo, as long as you
> don't care about the old history.
Right. But should that be the default? I don't think so. Therefore:
disable it, and if the user is absolutely sure to do dumb things, she'll
have to enable it explicitely.
> > - easily extend the shallow copy to a larger shallow one, or a full one.
>
> Hrm, I think there should also be a way to shrink a repo and "forget" old
> history occasionally (obviously, use of that feature would be highly
> discouraged).
Yes. And you need information about how shallow it used to be. My
suggestion was to store that information at a place specific to that
repository (see above).
> > > . Run `git fetch git://.../linux-2.6 master`, with a local ref
> > > pointing at v2.6.14 commit, to pretend that we have everything
> > > up to v2.6.14 to `upload-pack` running on the other end.
>
> > How about refs/tags/start_shallow?
>
> No, as that would imply that cloning from such a repo is disallowed.
See above.
> IMO, it may be a lot more robust to just have a list of "cutoff" object ids in
> .git/shallow instead of messing with grafts here, as adding or removing a line
> from that file is an easier thing to do for porcelain (or by hand) than
> rewriting the grafts file. Whether that list would be inclusive or exclusive
> would need to be decided still.
The functionality of cutoff objects is included in grafts functionality,
so why should we spend time on reimplementing a subset of features?
IMHO, adding and removing lines from scripts is fragile.
I beg your pardon, you want to edit this information *by hand*? Wow.
Ciao,
Dscho
^ 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