* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-08 17:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111107210134.GA7380@sigill.intra.peff.net>
On Mon, Nov 7, 2011 at 11:01 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 07, 2011 at 10:51:10PM +0200, Felipe Contreras wrote:
>
>> > What I don't understand is why it is not:
>> >
>> > git push --mirror <URL|remote>
>>
>> Because that pushes *everything*.
>
> Ahh, I think I see. It is doing --mirror, but only on a reduced refspec?
>
> In that case, is there a reason that:
>
> git push --prune <URL|remote> refs/heads/*
>
> would not do what you want (note that "--prune" does not exist, but I
> think it should).
I guess that should work.
>> > That's what I don't understand from your proposal. Your command is just
>> > pushing something to the remote, right? Why isn't "push" the command,
>> > and your sync options become options to push?
>>
>> How exactly? --sync-prune, --sync-new, --sync-all? But actually, I was
>> thinking on adding an option to sync the other way around; to get all
>> the remote branches and have them locally.
>
> If I understand correctly, you have three modes:
>
> 1. update remote refs with local values, prune anything remote that we
> don't have locally (--sync-prune)
>
> 2. update remote refs with local values, including pushing anything
> new that we don't have locally (--sync-new)
Anything new that we don't have *remotely*.
> 3. push new and prune (i.e., 1 and 2 together)
Yeap.
> If we had "git push --prune" as above, those would be:
>
> 1. git push --prune <remote> :
>
> I.e., use the "matching" refspec to not push new things, but turn
> on pruning.
I guess so, but ":" seems a bit obscure.
> 2. git push <remote> refs/heads/*
>
> Turn off pruning, but use an explicit refspec, not just "matching",
> which will push all local branches.
Isn't refs/heads/* the same as --all? BTW. I think --all is confusing,
should be --branches, or something.
> 3. git push --prune <remote> refs/heads/*
>
> Turn on both features.
Maybe 'git push' options should be reorganized (for 1.8.0):
--all -> --branches
--tags (same)
--mirror -> --all
--update = :
--prune (new)
In the meantime, we could add --update and --prune, which would not conflict.
>> Well, I usually have quite a lot of branches in my local repositories,
>> like a dozen of so. And I like to back them up in some remote
>> repository, however, not all the branches all the time. git push
>> --mirror not only pushes branches, but also tags (and I don't want
>> that), and even other refs. Does that clarifies things?
>
> That makes sense. But I think it fits in with git's current UI to do
> this via a combination of push options and refspecs. Even if we want to
> wrap it in some "git remote" command for convenience, I think what
> you're asking should be implemented as part of "git push".
Perhaps. I will give that a try, let's see how the code ends up.
But then, maybe similar options should be added to 'git fetch' to do
the same in the opposite direction, and that's where things get a bit
ugly:
--all -> rename to --all-remotes?
--prune -> rename to --prune-tracking?
--prune-local (new; prune local branches that don't exist on the remote)
--all (new; similar to 'git push --all' [--mirror])
--tags (same)
--update (new; similar to 'git push --update')
--branches (new; similar to 'git push --branches')
Somehow I fell there should be a 'sync' command somewhere to
differentiate these options from normal 'git fetch/push' commands.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Checkout first version of each file?
From: Dario Rodriguez @ 2011-11-08 17:20 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: Git Mailing List
In-Reply-To: <20111108150007.GA5261@kolya>
On Tue, Nov 8, 2011 at 12:00 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
> On Tue, Nov 08, 2011 at 11:17:27AM -0300, Dario Rodriguez wrote:
>> On Tue, Nov 8, 2011 at 11:02 AM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
>> > On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
>> >> Hello,
>> >>
>> >> My "issue" comes with my usage of git at work. I work with lots of
>> >> applications, each of them part of each system. There are lots of
>> >> processes and lots of subsystems, so I never clone the entire repo
>> >> into GIT, since it could be painful and slow. Even if I do so,
>> >> everyone else is using ClearCase, and their changes cannot be included
>> >> into my git repo until they "chickin". Sometimes, I must update
>> >> sources from FTP because the changes are not up to date in
>> >> ClearCase...
>> >>
>> >> So, I clone every file that I will need to work into GIT, so i can
>> >> work with these files having a better control (With ClearCase it's a
>> >> foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
>> >> don't know how many files I am going to change until I start coding
>> >> the requisites.
>> >>
>> >> In this cases, there is a situation that I don't know how to handle.
>> >> If I need to rollback every change made to every file I cannot just
>> >> checkout the initial commit, cause I've added files after that, and I
>> >> need their initial versions too.
>> >>
>> >> So, how can I checkout the first version of each file? (I know that
>> >> GIT tracks contents and not files, but the fact is that I need to keep
>> >> track on files, it's the real thing I work with)
>> >>
>> >> pd: Sorry about my Argentinian-English (if it sounds so)
>> >>
>> >> Thanks,
>> >> Dario
>> >> --
>> >> 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
>> >
>> > Is all files present in your latest commit? Or can there be deleted
>> > files that you also need to recover?
>> >
>> > --
>> > Med vänliga hälsningar
>> > Fredrik Gustafsson
>> >
>> > E-post: iveqy@iveqy.com
>> > Tel. nr.: 0733 60 82 74
>> >
>>
>> Every file in the latest working tree is also a tracked file. The
>> files are being added to the git repo, but not removed from it.
>>
>> In other words, the biggest set of files is the latest working tree,
>> and the smallest one is the first commit.
>>
>> Dario
>
> I can't see a pure git way of doing this. However, you already seem to
> use git in a very hackish-way. So here's a quick n' dirty solution (that
> is not very efficient).
>
> (not tested example code, that should be runned from the root-gitdir.):
>
> #!/bin/sh
> git reset --hard HEAD
> for f in `find`
> do
> commit=`git log $f | grep commit | tail -1`
> git checkout $commit $f
> done
>
> --
> Med vänliga hälsningar
> Fredrik Gustafsson
>
> E-post: iveqy@iveqy.com
> Tel. nr.: 0733 60 82 74
>
Yes, it's similar to my approach, except that I used 'git ls-files'
and 'git log --format=%H' to get the commit hash for each file
instead. Seems dirty, but reasonable if you think the git way.
Thank you,
Dario
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-08 16:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vhb2f1v7g.fsf@alter.siamese.dyndns.org>
On Mon, Nov 7, 2011 at 11:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> That makes sense. But I think it fits in with git's current UI to do
>> this via a combination of push options and refspecs. Even if we want to
>> wrap it in some "git remote" command for convenience, I think what
>> you're asking should be implemented as part of "git push".
>
> Yeah, I think it makes sense to give --prune to "push" just like "fetch"
> already has. These two are the primary (and in the ideal world, only)
> operations that talk to the outside world. "remote add -f" might have been
> a tempting "convenience" feature, but I personally think it probably was a
> mistake for the exact reason that letting anything but "push" and "fetch"
> talk to the outside world just invites more confusion. There does not have
> to be 47 different ways to do the same thing.
What about 'git remote update'?
--
Felipe Contreras
^ permalink raw reply
* Re: Benchmarks regarding git's gc
From: Brandon Casey @ 2011-11-08 16:40 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3E-YCMQQzJAU2wjjD-adpNy6bGb-=iUQ=p=bFTWxm+Ng@mail.gmail.com>
On Tue, Nov 8, 2011 at 5:34 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Has anybody seen these?
> http://draketo.de/proj/hg-vs-git-server/test-results.html#results
>
> Seems like a potential area of improvement.
I think this is a case of designing the problem space so that your
intended winner wins and your intended loser loses.
'git gc' is designed so that it can be run out-of-band. It doesn't
make a lot of sense to design your application so that the end-user
has to wait for git-gc to run, and I don't think anyone ever would.
But that is similar to how mercurial works, and that is why the author
of that page measured git's performance that way.
Off the top of my head, it seems to me that running 'git gc --auto' in
a cron job with SCHED_BATCH scheduling and some simple locking may
satisfy his requirement of keeping the repository size bounded and
ensuring that the pack operation does not affect the operation of the
web app.
-Brandon
^ permalink raw reply
* Re: Benchmarks regarding git's gc
From: Felipe Contreras @ 2011-11-08 16:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8DMAdjT8gsoSerkzNRvHgdcBWLaUd+-xHqXkV+hceo9rA@mail.gmail.com>
On Tue, Nov 8, 2011 at 4:37 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Tue, Nov 8, 2011 at 6:34 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> Has anybody seen these?
>> http://draketo.de/proj/hg-vs-git-server/test-results.html#results
>>
>> Seems like a potential area of improvement.
>
> The proportion between time and commits may have something to do with
> reachability test, where we traverse all commits and trees (I think
> twice in git-gc, one when it runs "reflog expire" and one "prune").
> packv4 is supposed to make tree traversing faster. Although it'd be
> best if we could avoid this test.
Is there someone working on a way to avoid this test?
--
Felipe Contreras
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2011, #02; Sun, 6)
From: Junio C Hamano @ 2011-11-08 16:21 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org
In-Reply-To: <4EB91D2C.6020504@atlas-elektronik.com>
Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:
> This breaks the 'quick-install-{doc,html,man}' make targets, btw.
Thanks. As the "push into kernel.org auto-rebuilds these branches"
infrastructure is no longer available, I think we should remove these
targets and description of them in the INSTALL file in the meantime.
Anybody care to do a big removal patch?
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Jeff King @ 2011-11-08 16:10 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Ori Avtalion, git
In-Reply-To: <CAKPyHN1cqG9-g1Q4iGbUOtfiXLc6EPcFH2cWNCep3af4cTdzSg@mail.gmail.com>
On Tue, Nov 08, 2011 at 09:52:26AM +0100, Bert Wesarg wrote:
> On Mon, Nov 7, 2011 at 23:55, Jeff King <peff@peff.net> wrote:
> > In the general case, you can't represent all failed hunks with conflict
> > markers, can you? I'm thinking something where we couldn't find any
> > relevant context. You know the lines from the original patch from the
> > hunk header, so you can drop the failed content from the patch in the
> > right spot. But how do you know how big a conflict marker to make for
> > the "current" side? The same number of lines as were in the hunk?
> > I think you'd end up with confusing conflict markers.
>
> GNU patch can produce conflict markers with the --merge option.
Hmm. Yeah, it does work, but as I feared, it can produce pretty awful
conflicts. Try this fairly straightforward setup (3 lines changed in the
middle of a file):
git init &&
seq 1 10 >file && git add file && git commit -m base &&
sed -i '3,5s/$/ master/' file && git commit -a -m master &&
git checkout -b other HEAD^ &&
sed -i '3,5s/$/ other/' file && git commit -a -m other
You can see what a real merge looks like:
git merge master &&
$EDITOR file
which is:
1
2
<<<<<<< HEAD
3 other
4 other
5 other
=======
3 master
4 master
5 master
>>>>>>> master
6
7
8
9
10
If you use "patch --merge", you get the same thing. Which is good. But
now try it with 10 lines changed out of 100:
rm -rf .git
git init &&
seq 1 100 >file && git add file && git commit -m base &&
sed -i '50,60s/$/ master/' file && git commit -a -m master &&
git checkout -b other HEAD^ &&
sed -i '50,60s/$/ other/' file && git commit -a -m other
Doing a merge will get you the same sensible results. But "patch
--merge" produces:
...
45
46
<<<<<<<
=======
47
48
49
50 master
...
60 master
61
62
63
>>>>>>>
47
48
49
50 other
51 other
52 other
53 other
...
which is not that helpful. Interestingly, I think it _should_ be able to
do the same thing here as it did on the 3-line case. So I'm not sure
why it doesn't.
But there are even more complex cases, like say "other" had added new
lines of new content at the beginning of the file, and messed up the
context lines that the patch was using. So I think in the general case,
you will end up with patches like the latter one. Just shoving the patch
hunk into the file with an empty preimage section. And that can even
still be useful, but you are relying on line counts then. If they're
off, it's going ot be quite confusing.
-Peff
^ permalink raw reply
* Re: [PATCH 0/3] Fix code issues spotted by clang
From: Elijah Newren @ 2011-11-08 16:05 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Jim Meyering, Fredrik Gustafsson,
Martin Waitz
In-Reply-To: <CACBZZX7bzFy_NCr4RTpYXXVmieaV7GrBfJgwdtCT1SwoXV_cGA@mail.gmail.com>
On Sun, Nov 6, 2011 at 5:33 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> "builtin/fast-export.c", line 54: warning: enum type mismatch: op "="
>
> This seems to me to be a legitimate issue we introduced in
> 2d8ad46919213ebbd7bb72eb5b56cca8cc3ae07f, Elijah?
>
> We're defining an enum like this:
>
> static enum { ABORT, VERBATIM, WARN, STRIP } signed_tag_mode = ABORT;
> static enum { ERROR, DROP, REWRITE } tag_of_filtered_mode = ABORT;
>
> And then doing:
>
> if (unset || !strcmp(arg, "abort"))
> tag_of_filtered_mode = ABORT; <-- Line 54
> else if (!strcmp(arg, "drop"))
> tag_of_filtered_mode = DROP;
> else if (!strcmp(arg, "rewrite"))
> tag_of_filtered_mode = REWRITE;
>
> Presumably that assignment should be "= ERROR".
Looking back at that patch, "abort" was the word that made the most
sense in the documentation and I was trying to make the code match.
Unfortunately, that would result in "ABORT" being redefined (to the
same value) so to squelch the compiler error I just went with the
quick hack of changing "ABORT" in the enum definition to "ERROR", but
didn't change "ABORT" later since "it had the same value anyway".
Yeah, not the safest programming practice.
I probably should have just used FILTERED_TAG_ABORT and changed the
signed_tag_mode enum to use SIGNED_TAG_ABORT (and then changed all
references to "ABORT" to match one of those two)...or maybe somehow
come up with a combined enum used for both (though WARN would only be
useful fo signed_tag_mode, REWRITE would only be useful for
tag_of_filtered_mode, etc.).
^ permalink raw reply
* Re: Checkout first version of each file?
From: Fredrik Gustafsson @ 2011-11-08 15:00 UTC (permalink / raw)
To: Dario Rodriguez; +Cc: Fredrik Gustafsson, Git Mailing List
In-Reply-To: <CABLeVKFkSP=2-kwsN4N+oLrPnijkpvV8Ki=Si4dpYXdzc+8ibQ@mail.gmail.com>
On Tue, Nov 08, 2011 at 11:17:27AM -0300, Dario Rodriguez wrote:
> On Tue, Nov 8, 2011 at 11:02 AM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
> > On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
> >> Hello,
> >>
> >> My "issue" comes with my usage of git at work. I work with lots of
> >> applications, each of them part of each system. There are lots of
> >> processes and lots of subsystems, so I never clone the entire repo
> >> into GIT, since it could be painful and slow. Even if I do so,
> >> everyone else is using ClearCase, and their changes cannot be included
> >> into my git repo until they "chickin". Sometimes, I must update
> >> sources from FTP because the changes are not up to date in
> >> ClearCase...
> >>
> >> So, I clone every file that I will need to work into GIT, so i can
> >> work with these files having a better control (With ClearCase it's a
> >> foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
> >> don't know how many files I am going to change until I start coding
> >> the requisites.
> >>
> >> In this cases, there is a situation that I don't know how to handle.
> >> If I need to rollback every change made to every file I cannot just
> >> checkout the initial commit, cause I've added files after that, and I
> >> need their initial versions too.
> >>
> >> So, how can I checkout the first version of each file? (I know that
> >> GIT tracks contents and not files, but the fact is that I need to keep
> >> track on files, it's the real thing I work with)
> >>
> >> pd: Sorry about my Argentinian-English (if it sounds so)
> >>
> >> Thanks,
> >> Dario
> >> --
> >> 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
> >
> > Is all files present in your latest commit? Or can there be deleted
> > files that you also need to recover?
> >
> > --
> > Med vänliga hälsningar
> > Fredrik Gustafsson
> >
> > E-post: iveqy@iveqy.com
> > Tel. nr.: 0733 60 82 74
> >
>
> Every file in the latest working tree is also a tracked file. The
> files are being added to the git repo, but not removed from it.
>
> In other words, the biggest set of files is the latest working tree,
> and the smallest one is the first commit.
>
> Dario
I can't see a pure git way of doing this. However, you already seem to
use git in a very hackish-way. So here's a quick n' dirty solution (that
is not very efficient).
(not tested example code, that should be runned from the root-gitdir.):
#!/bin/sh
git reset --hard HEAD
for f in `find`
do
commit=`git log $f | grep commit | tail -1`
git checkout $commit $f
done
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
^ permalink raw reply
* Re: Benchmarks regarding git's gc
From: Nguyen Thai Ngoc Duy @ 2011-11-08 14:37 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3E-YCMQQzJAU2wjjD-adpNy6bGb-=iUQ=p=bFTWxm+Ng@mail.gmail.com>
On Tue, Nov 8, 2011 at 6:34 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Has anybody seen these?
> http://draketo.de/proj/hg-vs-git-server/test-results.html#results
>
> Seems like a potential area of improvement.
The proportion between time and commits may have something to do with
reachability test, where we traverse all commits and trees (I think
twice in git-gc, one when it runs "reflog expire" and one "prune").
packv4 is supposed to make tree traversing faster. Although it'd be
best if we could avoid this test.
--
Duy
^ permalink raw reply
* git log --quiet bug?
From: Prasad Deshpande @ 2011-11-08 14:36 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I am new to the list so please let me know if I need to take this question somewhere else.
I am seeing a bug with git log --quiet. It doesn't seem to be quiet :-). Also I have seen cases where the exit status returned is not correct i.e. its 0 even if there is some output (although I cant seem to reproduce that problem at present).
--------------------------------------------------
[~/Work/ws/tools-common] git --version
git version 1.7.0.4
$ git log origin..HEAD
commit 632ff3eed4004ad76b7cd253643c66ce0f9223f1
Author: XXX
Date: Tue Nov 8 09:30:31 2011 -0500
test
$ git log origin..HEAD --quiet
commit 632ff3eed4004ad76b7cd253643c66ce0f9223f1
Author: XXX
Date: Tue Nov 8 09:30:31 2011 -0500
test
[~/Work/ws/tools-common] echo $?
1
--------------------------------------------------
thanks
-prasad
^ permalink raw reply
* Re: Checkout first version of each file?
From: Dario Rodriguez @ 2011-11-08 14:17 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: Git Mailing List
In-Reply-To: <20111108140243.GA4866@kolya>
On Tue, Nov 8, 2011 at 11:02 AM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
> On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
>> Hello,
>>
>> My "issue" comes with my usage of git at work. I work with lots of
>> applications, each of them part of each system. There are lots of
>> processes and lots of subsystems, so I never clone the entire repo
>> into GIT, since it could be painful and slow. Even if I do so,
>> everyone else is using ClearCase, and their changes cannot be included
>> into my git repo until they "chickin". Sometimes, I must update
>> sources from FTP because the changes are not up to date in
>> ClearCase...
>>
>> So, I clone every file that I will need to work into GIT, so i can
>> work with these files having a better control (With ClearCase it's a
>> foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
>> don't know how many files I am going to change until I start coding
>> the requisites.
>>
>> In this cases, there is a situation that I don't know how to handle.
>> If I need to rollback every change made to every file I cannot just
>> checkout the initial commit, cause I've added files after that, and I
>> need their initial versions too.
>>
>> So, how can I checkout the first version of each file? (I know that
>> GIT tracks contents and not files, but the fact is that I need to keep
>> track on files, it's the real thing I work with)
>>
>> pd: Sorry about my Argentinian-English (if it sounds so)
>>
>> Thanks,
>> Dario
>> --
>> 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
>
> Is all files present in your latest commit? Or can there be deleted
> files that you also need to recover?
>
> --
> Med vänliga hälsningar
> Fredrik Gustafsson
>
> E-post: iveqy@iveqy.com
> Tel. nr.: 0733 60 82 74
>
Every file in the latest working tree is also a tracked file. The
files are being added to the git repo, but not removed from it.
In other words, the biggest set of files is the latest working tree,
and the smallest one is the first commit.
Dario
^ permalink raw reply
* Re: Checkout first version of each file?
From: Fredrik Gustafsson @ 2011-11-08 14:02 UTC (permalink / raw)
To: Dario Rodriguez; +Cc: Git Mailing List
In-Reply-To: <CABLeVKF5P_sWwNX+OR_FX4+SPCN+SovZ2QuMmGGvJ-EskK7=YQ@mail.gmail.com>
On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
> Hello,
>
> My "issue" comes with my usage of git at work. I work with lots of
> applications, each of them part of each system. There are lots of
> processes and lots of subsystems, so I never clone the entire repo
> into GIT, since it could be painful and slow. Even if I do so,
> everyone else is using ClearCase, and their changes cannot be included
> into my git repo until they "chickin". Sometimes, I must update
> sources from FTP because the changes are not up to date in
> ClearCase...
>
> So, I clone every file that I will need to work into GIT, so i can
> work with these files having a better control (With ClearCase it's a
> foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
> don't know how many files I am going to change until I start coding
> the requisites.
>
> In this cases, there is a situation that I don't know how to handle.
> If I need to rollback every change made to every file I cannot just
> checkout the initial commit, cause I've added files after that, and I
> need their initial versions too.
>
> So, how can I checkout the first version of each file? (I know that
> GIT tracks contents and not files, but the fact is that I need to keep
> track on files, it's the real thing I work with)
>
> pd: Sorry about my Argentinian-English (if it sounds so)
>
> Thanks,
> Dario
> --
> 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
Is all files present in your latest commit? Or can there be deleted
files that you also need to recover?
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
^ permalink raw reply
* Checkout first version of each file?
From: Dario Rodriguez @ 2011-11-08 13:58 UTC (permalink / raw)
To: Git Mailing List
Hello,
My "issue" comes with my usage of git at work. I work with lots of
applications, each of them part of each system. There are lots of
processes and lots of subsystems, so I never clone the entire repo
into GIT, since it could be painful and slow. Even if I do so,
everyone else is using ClearCase, and their changes cannot be included
into my git repo until they "chickin". Sometimes, I must update
sources from FTP because the changes are not up to date in
ClearCase...
So, I clone every file that I will need to work into GIT, so i can
work with these files having a better control (With ClearCase it's a
foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
don't know how many files I am going to change until I start coding
the requisites.
In this cases, there is a situation that I don't know how to handle.
If I need to rollback every change made to every file I cannot just
checkout the initial commit, cause I've added files after that, and I
need their initial versions too.
So, how can I checkout the first version of each file? (I know that
GIT tracks contents and not files, but the fact is that I need to keep
track on files, it's the real thing I work with)
pd: Sorry about my Argentinian-English (if it sounds so)
Thanks,
Dario
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2011, #02; Sun, 6)
From: Stefan Näwe @ 2011-11-08 12:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <7vehxl57lt.fsf@alter.siamese.dyndns.org>
Am 06.11.2011 21:17, schrieb Junio C Hamano:
> Here are the topics that have been cooking. Commits prefixed with '-' are
> only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
>
> [...]
>
> With all the topics and integration branches but not todo, html or man:
>
> https://github.com/gitster/git
>
> I will stop pushing the generated documentation branches to the above
> repositories, as they are not sources.
This breaks the 'quick-install-{doc,html,man}' make targets, btw.
> These branches are pushed to their own separate repositories instead:
>
> git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
> git://repo.or.cz/git-{htmldocs,manpages}.git/
> https://code.google.com/p/git-{htmldocs,manpages}.git/
> https://github.com/gitster/git-{htmldocs,manpages}.git/
I had to create remotes for those repositories (named htmldocs and manpages)
and put this into config.mak to make it work again:
HTML_REF=htmldocs/master
DOC_REF=manpages/master
Just FYI...
Stefan
--
----------------------------------------------------------------
/dev/random says: Brain: The apparatus with which we think that we think.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Benchmarks regarding git's gc
From: Felipe Contreras @ 2011-11-08 11:34 UTC (permalink / raw)
To: git
Has anybody seen these?
http://draketo.de/proj/hg-vs-git-server/test-results.html#results
Seems like a potential area of improvement.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git-receive-pack missing credentials ?
From: François Dagorn @ 2011-11-08 10:50 UTC (permalink / raw)
To: git
In-Reply-To: <4EB7FA3A.8070908@univ-rennes1.fr>
It was an ExecCGI issue :
when adding "Options ExecCGI" on the
directory hosting git repositories, everything was ok.
François
^ permalink raw reply
* Re: git-receive-pack missing credentials ?
From: François Dagorn @ 2011-11-08 10:17 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111108T091907-908@post.gmane.org>
François Dagorn <Francois.Dagorn <at> univ-rennes1.fr> writes:
What happens : git-http-backend is not called at all !
ScriptAlias /git/ /usr/local/libexec/git-core/git-httpd-backend/
is not relevant, I don't know why.
François
^ permalink raw reply
* How to resolve git stash conflict without adding to index?
From: Sven Bachmann @ 2011-11-08 9:10 UTC (permalink / raw)
To: git
Hi Git-Group,
from time to time I've got to "git stash" a bunch of files (about 20).
My problem is, sometimes "git stash pop" conflicts and all files are
added to the index - which is not what I want.
I just want to have the same behavior like "git stash pop" without
conflict has. Resolving the conflict is okay, but not "git reset HEAD"
to all other files, which I don't want to commit now.
Is there a possibility that "git stash pop" does not add all files to
the index when a conflict appears?
I've already asked this question on stackoverflow (
http://stackoverflow.com/questions/7751555/how-to-resolve-git-stash-conflict-without-commit ) - maybe this helps a bit better to describe the
problem.
Please add me to CC if possible as I'm not subscribed to this list and
reading it in the browser.
Thanks a lot in advance!
Sven
^ permalink raw reply
* [fyi] patches used by git distributors
From: Jonathan Nieder @ 2011-11-08 9:02 UTC (permalink / raw)
To: git
Hi,
In an ideal world, each patch applied by downstream distributors would
fall into one of two categories: (a) adapting the package to some
esoteric distro-specific requirement (i.e., special-interest patches)
or (b) in the process of being generalized and reviewed for eventual
application upstream, so everyone can benefit from it. Unfortunately
that takes time. I should do better --- sorry about that.
As an experiment, here's a quick summary of the patches being used
in Debian, for people curious about that and for people interested in
grabbing useful patches to polish and not knowing where to start.
(Links point to relevant discussion, not necessarily the patch used):
Frédéric Brière (1):
gitk: Skip over AUTHOR/COMMIT_DATE when searching all fields [1]
Gerrit Pape (1):
bug#506445: hooks/post-receive-email: set encoding to utf-8 [2]
Jonathan Nieder (12):
remove shebang line from shell libraries [3]
pre-rebase hook: capture documentation in a <<here document [4]
gitk: use symbolic font names "sans" and "monospace"
transport: expose git_tcp_connect and friends in new tcp.h [5]
daemon: make host resolution into a separate function [5]
daemon: move locate_host to tcp.c [5]
tcp: unify ipv4 and ipv6 code paths [5]
daemon: check for errors retrieving IP address [5]
tcp: make dns_resolve return an error code [5]
transport: optionally honor DNS SRV records [5]
srv: make errors less quiet [5]
Makefile: add a knob to turn off hardlinks within same directory [6]
The patches listed above are on the candidate+patches branch of [7].
Questions and improvements can go to git@packages.debian.org.
A few other packaging projects:
- git://pkgs.fedoraproject.org/git.git master --- 3 patches (using
SERVER_NAME for home link, reviving vc-git.el, compatibility with
newer cvsps)
- http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/git/files/ ---
1 patch (capping individual reads and writes at INT_MAX chars)
- https://build.opensuse.org/package/files?package=git&project=devel%3Atools%3Ascm
--- 4 patches (a python build fix, making gitweb::prevent_xss
default to true, turning off hardlinks for builtins at installation
time, protecting COMP_WORDBREAKS from mangling in the completion
script)
- http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-vcs/git/files/
--- 1 patch (a NO_CVS knob for the makefile). Very nice.
- http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/scmgit-base/patches/
--- 3 patches (putting CFLAGS at the end of ALL_CFLAGS so it can
override BASIC_CFLAGS, setting INSTALLDIRS=vendor in perl makefile,
improving tk support on Darwin 8)
- http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/git/patches/ ---
8 patches (updating OpenBSD makefile defaults, using raw perlio in
gitweb blob view, removing "set -e" in t9117, passing --text [well,
-a] to grep in t9200, avoiding nonportable regex \+ in t9400)
- ftp://ftp.cygwin.org/pub/cygwin/release/git/git-1.7.5.1-1-src.tar.bz2
--- 3 patches (tcl 8.4.1 support, updating Cygwin makefile defaults,
case-insensitive path comparison in makefile, special Windows-specific
wish script preamble)
[1] http://thread.gmane.org/gmane.comp.version-control.git/142160
[2] http://thread.gmane.org/gmane.comp.version-control.git/181737
[3] http://bugs.debian.org/368792
[4] http://thread.gmane.org/gmane.comp.version-control.git/150737
[5] http://thread.gmane.org/gmane.comp.version-control.git/175106
[6] http://thread.gmane.org/gmane.comp.version-control.git/183361
[7] http://smarden.org/git/git.git
gitweb: http://repo.or.cz/w/git/debian.org
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Bert Wesarg @ 2011-11-08 8:52 UTC (permalink / raw)
To: Jeff King; +Cc: Ori Avtalion, git
In-Reply-To: <20111107225508.GB28188@sigill.intra.peff.net>
On Mon, Nov 7, 2011 at 23:55, Jeff King <peff@peff.net> wrote:
> In the general case, you can't represent all failed hunks with conflict
> markers, can you? I'm thinking something where we couldn't find any
> relevant context. You know the lines from the original patch from the
> hunk header, so you can drop the failed content from the patch in the
> right spot. But how do you know how big a conflict marker to make for
> the "current" side? The same number of lines as were in the hunk?
> I think you'd end up with confusing conflict markers.
GNU patch can produce conflict markers with the --merge option.
Bert
>
> -Peff
^ permalink raw reply
* Re: git-receive-pack missing credentials ?
From: François Dagorn @ 2011-11-08 8:26 UTC (permalink / raw)
To: git
In-Reply-To: <CALUzUxpiOoY3Qy0oXzgioBGkZyBF_vpHV3OHm-DWfChR9pPHHA@mail.gmail.com>
Tay Ray Chuan <rctay89 <at> gmail.com> writes:
>
> On Mon, Nov 7, 2011 at 11:33 PM, François Dagorn
>
> Can you update your git installation and try again? v1.7.3.4 sounds
> pretty old (almost a year).
>
On the server side I'm using the last 1.7.7.2 and 1.7.3.4 is on
the client side used for testing.
When apache is configured to serve without authentication, everything
is ok !
PS: I don't know where to report but there are mistakes (IMHO) in the
git-http-backend man page : the LocationMatch directive cannot be used
to restrict access to "receive-pack" because "receive-pack" does not
take part of the URL but only in the QUERY_STRING.
GET /test13/info/refs?service=git-receive-pack
****
Cheers.
François
^ permalink raw reply
* Re: how to merge sub directory or file?
From: Emily Ren @ 2011-11-08 7:08 UTC (permalink / raw)
To: Konstantin Khomoutov; +Cc: git
In-Reply-To: <20111107193708.6cf2ae81.kostix@domain007.com>
Hi Kon,
Thank you ! I tried that method, it failed on read-tree because
B/dir3 already exists, Cannot bind.
$ git read-tree --prefix=dir3 -u A:dir3
error: Entry 'dir3/file1' overlaps with 'dir3/file1'. Cannot bind.
And my case is that not all A's sub direcotries are in B.
For example, in A's dir3, there are file1, dir4 and dir5. But in B's
dir3, only file1 and dir4 exist, there's no dir5. How to handle this
case ?
Thanks,
Emily
On Mon, Nov 7, 2011 at 11:37 PM, Konstantin Khomoutov
<flatworm@users.sourceforge.net> wrote:
>
> On Mon, 7 Nov 2011 22:54:18 +0800
> Emily <lingyan.ren@gmail.com> wrote:
>
> > I have two git projects A and B, content of B is subset of A. For
> > example, Project A and B's tree are as below:
> [...]
> > When there's new changes in project A, how can I merge them to
> > project B without changing B's directory structure?
> >
> > Your help will be highly appreciated.
> Subtree merging maybe?
> See http://progit.org/book/ch6-7.html
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Junio C Hamano @ 2011-11-08 6:15 UTC (permalink / raw)
To: Jeff King; +Cc: Ori Avtalion, git
In-Reply-To: <20111108054643.GC29643@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But I think there are two questions:
>
> 1. Should am's 3-way fallback be made more easily available to users
> of regular "apply"?
>
> 2. Short of doing a 3-way merge, are there better ways to represent
> failed hunks in the patch target itself, rather than saving ".rej"
> files?
>
> I'm actually not sure which one Ori was asking about.
Me neither, but if I have to guess it would be the former. If there were a
solution better than ".rej" in 2-way context, surely "patch" would have
implemented it 10 years before we started ;-).
^ permalink raw reply
* Re: pretty placeholders for reflog entries
From: Jeff King @ 2011-11-08 5:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jack Nagel, git
In-Reply-To: <7v8vnr1oww.fsf@alter.siamese.dyndns.org>
On Mon, Nov 07, 2011 at 03:41:19PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > It would be a little nicer to provide explicit date placeholders, but we
> > can't quite make them match the author-date specifiers, because "gd" is
> > taken. We could add %gt, %gr, etc. But in the long run, I'd like to
> > move to considering most of %ar, %at, etc to be historical, and have
> > something like "%ad(short)" be the official way of picking different
> > date formats[1]. And then the reflog placeholders could learn
> > "%gt(short)". So making more reflog placeholders right now just feels
> > like cluttering a namespace I'd like to get changed eventually.
>
> I tend to agree with the direction.
>
> As we are not adding anything new before the 1.7.8 final, I'd rather ask
> you to hold onto this and other changes in your footnote, instead of
> having me to carry them in 'pu', which is an integration branch even less
> official than it would otherwise be during the freeze period.
Sure. I'll re-send the patch once the release is out. That will also
give Jack and any other interested parties time to comment and test.
-Peff
^ 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