* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jay Soffian @ 2008-07-02 2:21 UTC (permalink / raw)
To: Adam Brewster; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <c376da900807011916j5a3032een4587619535061b72@mail.gmail.com>
On Tue, Jul 1, 2008 at 10:16 PM, Adam Brewster <adambrewster@gmail.com> wrote:
> But of course one function returns two very different things depending
> on what's on the left side of the equals sign. That makes perfect
> sense.
Context should be the very first thing taught in any Perl tutorial,
lest ye end up in jail:
http://yro.slashdot.org/article.pl?sid=01/03/13/208259
:-)
j.
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Adam Brewster @ 2008-07-02 2:16 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <76718490807011910p37ac9bcbjf9fa9748a2eb2e@mail.gmail.com>
On Tue, Jul 1, 2008 at 10:10 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Tue, Jul 1, 2008 at 9:36 PM, Adam Brewster <adambrewster@gmail.com> wrote:
>> Maybe I'm a idiot, but I can't find any built-in date to string
>> functions that do nice things like print the date the way the user
>> says he likes to look at dates.
>
> perldoc -f localtime
>
But of course one function returns two very different things depending
on what's on the left side of the equals sign. That makes perfect
sense.
> j.
>
Thank you.
Adam
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Adam Brewster @ 2008-07-02 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vzlp1jh1o.fsf@gitster.siamese.dyndns.org>
>
> Well, I have a moderately strong objection to this.
>
> This very much feels like adding a missing feature to "git bundle" command
> itself. Why isn't it a new option to it?
>
Mostly because this was an easy way to accomplish the same thing. If
this is popular, then it can be added to git-bundle.
> For that matter, I am not sure how this integrates to a larger workflow.
> You have a site (or more) to "push" your changes to, and you would need to
> remember up to which revisions you have given out bundles to. To remember
> which site is at what basis level, you would need an extra infrastructure
> than what this separate command offers (and "I'll have a yet another layer
> of wrapper to this script" is not a good answer. That wrapper can simply
> read the tips from the bundle and record them without your script, and the
> wrapper can use the previously recorded information to use the new bottom
> refs when creating a new bundle again without using your script).
The intent is to use one basis per site, not one per bundle, so the
first iteration is
A$ git-bundle create package.git --all
B$ git-clone package.git package
A$ git-bundle --update siteB < package.git
and thereafter it's
A$ git-bundle siteB | git-bundle create package.git --all --stdin
B$ git-pull
A$ git-bundle --update siteB < package.git
There's no issue of remembering which site is at which basis level,
because each site gets it's own basis.
If you're worried about hundred of sites, this is a bad solution. I
happen to be worried about three sites, so this works well for me.
>
> Perhaps it would be sufficient to have a new option to git-bundle. "write
> basis information under this name, so that I can reuse it in the next
> invocation", and "I am not giving the bottom refs to create this bundle;
> read them from the existing basis with this name". It probably is easiest
> to operate if these two are simply a new single option, like this...
>
> [...]
I agree than git-bundle --basis is a better syntax than git-basis |
git-bundle --stdin.
I do, however, think that creating the bundle and updating the basis
should be two separate steps. Mostly because the fact that I created
a bundle and planned to install it on another machine does not
guarantee that the resources of that bundle exist on the other
machine. (I may need to stop for coffee and ... who knows?) Also, in
practice, I always use the intersection of all of my remote bases when
I create a bundle, and I frequently use them in places other than
where I intended. Yes it's a pain to go back to git-basis --update,
but it's better than trying to git-pull from a bundle that's missing
objects.
Adam
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jay Soffian @ 2008-07-02 2:10 UTC (permalink / raw)
To: Adam Brewster; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <c376da900807011836i76363d74n7f1b87d66ba34cd6@mail.gmail.com>
On Tue, Jul 1, 2008 at 9:36 PM, Adam Brewster <adambrewster@gmail.com> wrote:
> Maybe I'm a idiot, but I can't find any built-in date to string
> functions that do nice things like print the date the way the user
> says he likes to look at dates.
perldoc -f localtime
j.
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Adam Brewster @ 2008-07-02 1:36 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jakub Narebski
In-Reply-To: <20080701095117.GC5853@sigill.intra.peff.net>
Hi Jeff,
Thank you for your feedback. I have made most of the code changes you
suggested, and am in the process of writing tests, but it looks like
some others on the list have more serious objections, so I'll hold of
on that until I think it might actually be accepted.
In the mean time, I have a couple of responses to your comments below.
>
> When a new feature depends on other, more generic improvements
> to existing code, it is usually split into two patches. E.g.,
>
> 1/2: add --stdin to git-bundle
> 2/2: add git-basis
>
> with the advantages that:
>
> - it is slightly easier to review each change individually
> - it is easier for other features to build on the generic improvement
> without requiring part 2, especially if part 2 is questionable
>
> As it happens in this case, I think in this case the change was already
> easy to read, being logically separated by file, so I am nitpicking
> somewhat. But splitting changes is a good habit to get into.
>
Makes sense, I thought it was small enough for one commit, but I'll
split it up when I resubmit.
>> + if (len && line[len - 1] == '\n')
>> + line[--len] = 0;
>
> Style: we usually spell NUL as '\0'.
>
Okay. I can also include a third patch for the code I cut-and-pasted.
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 11a7eae..73fe334 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -582,7 +582,7 @@ static void read_revisions_from_stdin(struct rev_info *revs)
while (fgets(line, sizeof(line), stdin) != NULL) {
int len = strlen(line);
if (len && line[len - 1] == '\n')
- line[--len] = 0;
+ line[--len] = '\0';
if (!len)
break;
if (line[0] == '-')
>> diff --git a/git-basis b/git-basis
>> new file mode 100755
>
> This should be git-basis.perl, with accompanying Makefile changes.
>
>> +if ( ! -d "$d/bases" ) {
>> + system( "mkdir '$d/bases'" );
>> +}
>
> Yikes. This fails if $d contains an apostrophe. You'd want to use
> quotemeta to properly shell out. But there's no need at all to shell out
> here, since perl has its own mkdir call.
>
Made both of these changes.
>> +if ( $#ARGV == -1 ) {
>> + print "usage: git-basis [--update] basis1...\n";
>> + exit;
>
> Usage should probably go to STDERR.
>
Makes sense.
>> + my %new = ();
>> + while (<STDIN>) {
>> + if (!/^^?([a-z0-9]{40})/) {next;}
>> + $new{$1} = 1;
>> + }
>
> Why make a hash when the only thing we ever do with it is "keys %new"?
> Shouldn't an array suffice?
>
It's probably a non-issue, but using a hash will prevent duplicates.
>> + foreach my $f (@ARGV) {
>> + my %these = ();
>> + open F, "<$d/bases/$f" || die "Can't open bases/$f: $!";
>
> Style: I know we are not consistent within git, but it is usually better
> to use local variables for filehandles these days. I.e.,
>
> open my $fh, "<$d/bases/$f"
>
Okay.
>> + open F, ">>$d/bases/$f" || die "Can't open bases/$f: $!";
>
> So the basis just grows forever? That is, each time we do a bundle and
> basis update, we add a line for every changed ref, and we never delete
> any lines. But having a commit implies having all of its ancestors, so
> in the normal case (i.e., no rewind or rebase) we can simply replace old
> objects if we know they are a subset of the new ones (which you can
> discover with git-merge-base). For the rewind/rebase case, probably
> these lists should get pruned eventually for non-existent objects.
>
If all goes well then you're right, but I thought old objects should
be kept around in case the user has some reason to manually delete
them. As it is, you can go into the basis file and delete everything
past a given date line and be back where you were. If I delete the
redundant objects, then that's not always possible.
It'd be nice if it could prune old objects (maybe older than 6 months,
or settable by git-config) that are redundant, but I currently have no
need for such functionality.
I also hadn't thought about rebasing. Objects that don't exist
shouldn't hurt anything though. Just a waste of a little disk space.
If pruning is ever put in, objects that don't exist can be deleted.
> But maybe it is not worth worrying about this optimization at first, and
> we can see if people complain. In that case, it is perhaps worth a note
> in the 'Bugs' section (or 'Discussion' section) of the manpage.
>
Agree. I put it under bugs.
>> + print F "\#" . `date`;
>
> I don't think there are any portability issues with 'date' (especially
> since it appears to be just a comment here, so we don't really care
> about the format), but in general I think it is nicer to use perl's date
> functions just for consistency's sake.
>
Maybe I'm a idiot, but I can't find any built-in date to string
functions that do nice things like print the date the way the user
says he likes to look at dates.
I updated the comment line to be "# <git-date> // `date`" where
git-date is as per git-fast-import (seconds since 1969 +/-TZ). If
automatic pruning ever happens, the git-date will be used, so `date`
is just for humans.
>
> Notably absent: any tests.
>
Working on those. I'll also include tests for git-bundle.
Adam
^ permalink raw reply related
* Re: [RFC/PATCH 2/4] Add git-sequencer prototype documentation
From: Junio C Hamano @ 2008-07-02 1:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephan Beyer, git, Johannes Schindelin
In-Reply-To: <200807020239.41613.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> No. It is "git-update-ref <ref> HEAD".
>
> So what do you envision would this be used for?
A simple answer and a more elaborate one.
* It is the final step of "git rebase" which detaches HEAD while it
operates these days.
* You can drive sequencer backend from a front-end that rewrite history
while rewriting tags, like filter-branch does.
>>> What is important is: does it update reflog (correctly)?
That is not very important question, as reflog updates would happen as
long as you use update-ref automatically.
Much more important question you did not ask is how it would interact with
"sequencer --abort". Ideally it should rewind the ref update (and without
relying on the user having reflog on that ref).
I however personally feel that this "ref" thing is being a bit too
ambitious.
^ permalink raw reply
* Re: [RFC/PATCH 2/4] Add git-sequencer prototype documentation
From: Jakub Narebski @ 2008-07-02 0:39 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <20080701195033.GD5301@leksak.fem-net>
Hi!
On Tue, 1 July 2008, Stephan Beyer wrote:
> On Tue, Jul 01, 2008 at 08:04:10PM +0200, Jakub Narebski wrote:
>> On Tue, 1 Jul 2008, Stephan Beyer wrote:
>>> On Tue, Jul 01, 2008 at 06:02:54AM -0700,
>>> Jakub Narebski <jnareb@gmail.com> wrote:
>>>> Stephan Beyer wrote:
[...]
>>>>> +ref <ref>::
>>>>> + Set ref `<ref>` to the current HEAD, see also
>>>>> + linkgit:git-update-ref[1].
>>>>
>>>> So this functions like "git reset --soft <ref>", isn't it?
>>>
>>> No. Why do you think that? `ref` is set, and not HEAD.
>>> I think the description makes that clear.
>>
>> Ah. I'm sorry. So it is like "git branch <ref>", isn't it?
Actually I meant "git branch -f <ref>" here. But I forgot that it
can be used to create lightweight tags, too.
> No. It is "git-update-ref <ref> HEAD".
So what do you envision would this be used for?
>> What is important is: does it update reflog (correctly)?
>
> Good question. The reflog is another mistery to me that I haven't really
> cared about, because I haven't used it yet myself.
> At least the reflog test cases for git rebase -i in the test suite pass.
> (Of course, this is only a weak indication that it works as it should.)
You have 'branch' (<onto>) reflog, HEAD reflog, and reflog for '<ref>'.
While 'branch' reflog should I think record only start and end of
sequencer, or rather git-am or git-rebase, I'm not sure what to do about
HEAD reflog... We should fill reflog for <ref>, to be able to revert
easily.
>>>>> +squash [options] --from <mark>::
> [...]
>>> Here an example why it is useful for user-editing:
>>>
>>> (on commit f00babe)
>>> mark :1
>>> pick badcebab
>>> patch foo
>>> pick dadadada
>>> squash -m "Foo the cebab" --signoff --from :1
>>>
>>> This squashes all between the mark and the squash into one commit,
>>> on top of f00babe.
>>
>> Ah, so squash --from <mark> picks up everything since "mark <mark>",
>> but does not include marked commit! Clever! In this case allowing
>> only <mark> is a good idea, IMVHO.
>
> Good, thanks :)
Although I guess having example would make it clear from the go...
Good work!
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Mark Levedahl @ 2008-07-02 0:16 UTC (permalink / raw)
To: git; +Cc: Adam Brewster, git, Jakub Narebski
In-Reply-To: <7vzlp1jh1o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> Well, I have a moderately strong objection to this.
>
> This very much feels like adding a missing feature to "git bundle" command
> itself. Why isn't it a new option to it?
>
I have implemented (in script form) a different approach: basically, I just keep
a local copy of the refs pushed out via bundle in refs/remotes/*, just as for
any other remote, and then use those as the basis for later bundles. My longer
term goal is to integrate this into git push, so that with a properly configured
remote "git push foo" will create a bundle based upon the local knowledge of the
remote's basis and update the local copy of the refs.
For reference, this is the script I currently use ...
#!/bin/sh
# usage
if test $# -lt 4
then
echo "usage: $0 repoDirectory bundleName remote [git-for-each-ref args]"
exit 1
fi
# must be at toplevel
cd $1 || exit 1
cd ./$(git rev-parse --show-cdup) || exit 1
bundleName=$2
remote=$3
shift 3
# get list of what we want to bundle up
newrefs=$(git for-each-ref --format="%(refname)" $*)
# get list of the current bundle
basis=$(git for-each-ref --format="^%(objectname)" refs/remotes/$remote)
# create the bundle
if git bundle create "$bundleName" $newrefs $basis
then
# update our record of basis from the bundle
git bundle list-heads "$bundleName" | \
while read sha1 refname
do
git update-ref refs/remotes/"$remote"/"${refname##refs/}" $sha1
done
else
rm -f "$bundleName"
fi
Mark
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Junio C Hamano @ 2008-07-01 23:55 UTC (permalink / raw)
To: Adam Brewster; +Cc: git, Jakub Narebski
In-Reply-To: <c376da900806301549r6044cd35r5a23baa405570808@mail.gmail.com>
"Adam Brewster" <adambrewster@gmail.com> writes:
> Git-basis is a perl script that remembers bases for use by git-bundle.
> Code from rev-parse was borrowed to allow git-bundle to handle --stdin.
>
> Signed-off-by: Adam Brewster <adambrewster@gmail.com>
> ---
> As promised, here's another patch with documentation. The code is
> identical to the previous version.
>
> I know this is a minor patch, but I think the result is a more usable
> git-bundle feature, and I'd like to see it included in future releases
> if there are no objections.
Well, I have a moderately strong objection to this.
This very much feels like adding a missing feature to "git bundle" command
itself. Why isn't it a new option to it?
For that matter, I am not sure how this integrates to a larger workflow.
You have a site (or more) to "push" your changes to, and you would need to
remember up to which revisions you have given out bundles to. To remember
which site is at what basis level, you would need an extra infrastructure
than what this separate command offers (and "I'll have a yet another layer
of wrapper to this script" is not a good answer. That wrapper can simply
read the tips from the bundle and record them without your script, and the
wrapper can use the previously recorded information to use the new bottom
refs when creating a new bundle again without using your script).
Perhaps it would be sufficient to have a new option to git-bundle. "write
basis information under this name, so that I can reuse it in the next
invocation", and "I am not giving the bottom refs to create this bundle;
read them from the existing basis with this name". It probably is easiest
to operate if these two are simply a new single option, like this...
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index f6a0612..d3e0716 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -9,7 +9,7 @@ git-bundle - Move objects and refs by archive
SYNOPSIS
--------
[verse]
-'git-bundle' create <file> <git-rev-list args>
+'git-bundle' create [--basis=<filename>] <file> <git-rev-list args>
'git-bundle' verify <file>
'git-bundle' list-heads <file> [refname...]
'git-bundle' unbundle <file> [refname...]
@@ -37,6 +37,17 @@ create <file>::
Used to create a bundle named 'file'. This requires the
git-rev-list arguments to define the bundle contents.
+--basis=<filename>;;
+ Record the tips of resulting bundle to the file whie creating the
+ bundle, so that the information can be used when later creating a
+ new bundle to incrementally update a repository that resulting
+ bundle has already been applied to.
++
+If the named file exists, it should name the file given to this
+option in a previous invocation of 'git-bundle create' command.
+The tips of history recorded in the file is read and the resulting
+bundle will require them.
+
verify <file>::
Used to check that a bundle file is valid and will apply
cleanly to the current repository. This includes checks on the
@@ -165,6 +176,26 @@ $ git pull bundle
would treat it as if it is talking with a remote side over the
network.
+- Use basis file to keep track.
+
+------------
+$ git bundle create --basis=siteA.basis 2008-07-01.bndl master
+------------
+
+The new file `siteA.basis` records the tip commits in the created
+bundle. Give `2008-07-01.bndl` to 'site A'. Then later:
+
+------------
+$ git bundle create --basis=siteA.basis 2008-08-01.bndl master
+------------
+
+This invocation will read the existing `siteA.basis` file, reads the tip
+commits recorded there, and excludes the history reachable from these
+commits from the resulting `2008-08-01.bndl` bundle. You can give this to
+'site A'; as long as they have extracted the previous bundle, it is
+sufficient to bring them up-to-date.
+
+
Author
------
Written by Mark Levedahl <mdl123@verizon.net>
Hmm?
^ permalink raw reply related
* Re: [PATCH 14/14] Build in merge
From: Junio C Hamano @ 2008-07-01 23:55 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <0cde1e7c930589364318b2d0344b345453e23586.1214918017.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> Interdiff: git diff 01a7dae..7709df7
>
> Individual commits (there is only one change this time): git log 7709df7
>
> Ah and please don't forget to apply the testsuite fix I sent in
> $gmane/86981. (Or is it easier if I resend the whole series?)
Are you sure about that? I've been deliberately fixing that patch.
As far as I understand it, your series:
- starts out building infrastructure;
- adds tests;
- finally replaces git-merge with the new implementation.
and the test in question comes when git-merge built from that version is
still the scripted version with limitation.
So if you build and test after applying individual steps (you sure do
that, don't you?), the test has to start with expecting failure (from the
scripted git-merge that has the octopus limitation) and then later changed
to expect success when git-merge is replaced.
Have you looked at the series I fixed up before pushing out in 'pu' last
night, specifically 5948e2a and 01a7dae? If you actually built and tested
5948e2a, you'd notice that the test in that commit *must* expect failure.
^ permalink raw reply
* Re: [PATCH?] Fix 'git show' on signed tag of signed tag of commit
From: Junio C Hamano @ 2008-07-01 23:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
In-Reply-To: <1214905624-29517-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The cmd_show loop resolves tags by showing them, then pointing the
> object to the 'tagged' member. However, this object is not fully
> initialized; it only contains the SHA1. (This resulted in a segfault
> if there were two levels of tags.) We apply parse_object to get a
> full object.
>
> Noticed by Kalle Olavi Niemitalo on IRC.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> I'm not 100% sure this is the right fix; I just had a quick stab at
> the code, made a fix and tested it. It probably leaks memory too, not
> sure if this is a problem.
The code looks good. It should not have been accessing the object without
making sure it has been parsed.
And it's not a leak. Once you instantiate "struct object" derived class,
we hold onto it (at least to its skeleton).
Thanks.
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Junio C Hamano @ 2008-07-01 23:55 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Ingo Molnar, git
In-Reply-To: <20080701114118.GU4729@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Jul 01, 2008 at 01:22:35PM +0200, Ingo Molnar <mingo@elte.hu> wrote:
>> [ Oh, and i could switch between git versions without having to rebuild
>> ;-) ]
>
> I remember about a mail from Junio where he wrote he has a lot of
> versions installed under ~/git/git-version. So usually he has git from
> next as default and he can try ~/git/git-1.5.4/git if he want 1.5.4,
> etc.
Yup.
I have $HOME/git-active/bin on my $PATH and then these:
lrwxrwxrwx 1 junio junio 10 2008-05-25 18:13 /home/junio/git-active -> git-master
drwxr-sr-x 6 junio junio 4096 2007-04-04 02:49 /home/junio/git-maint
drwxr-sr-x 5 junio junio 4096 2007-12-14 22:46 /home/junio/git-master
drwxr-sr-x 6 junio junio 4096 2008-06-23 22:02 /home/junio/git-next
drwxr-sr-x 7 junio junio 4096 2007-12-02 02:52 /home/junio/git-pu
drwxr-sr-x 4 junio junio 4096 2006-10-14 22:43 /home/junio/git-snap-v1.0.0
drwxr-sr-x 4 junio junio 4096 2007-01-11 22:27 /home/junio/git-snap-v1.1.0
drwxr-sr-x 4 junio junio 4096 2007-01-11 22:26 /home/junio/git-snap-v1.2.0
drwxr-sr-x 4 junio junio 4096 2007-01-11 22:24 /home/junio/git-snap-v1.3.0
...
drwxr-sr-x 5 junio junio 4096 2008-06-07 12:11 /home/junio/git-snap-v1.5.5.4
drwxr-sr-x 5 junio junio 4096 2008-06-26 17:33 /home/junio/git-snap-v1.5.5.5
drwxr-sr-x 5 junio junio 4096 2008-06-25 14:41 /home/junio/git-test
my "Make" and "Doit" scripts that arrange the $(prefix) for these builds
are found in my 'todo' branch.
^ permalink raw reply
* Re: [PATCH] git-add--interactive: manual hunk editing mode
From: Junio C Hamano @ 2008-07-01 23:54 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jeff King
In-Reply-To: <1214912674-9443-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Jeff King wrote:
>> Now that this is in next, maybe it is a good time to repost the
>> add--interactive patch (it should be independent of Dscho's 2/2 "add -e"
>> patch).
>
> It is independent, so I suppose you're right. (Dscho mentioned in
> passing he might repost "add -e" himself.)
Thanks, both.
^ permalink raw reply
* Re: [PATCH 3/7] Documentation: complicate example of "man git-command"
From: Junio C Hamano @ 2008-07-01 23:54 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Jonathan Nieder, git, Christian Couder, Nguyen Thai Ngoc Duy,
Jon Loeliger
In-Reply-To: <20080701162358.GA18305@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Mon, Jun 30, 2008 at 05:10:25PM -0500, Jonathan Nieder wrote:
>> The manual page for the command invoked as "git clone" is named
>> git-clone(1), and similarly for the rest of the git commands.
>> Make sure our first example of this in tutorials makes it clear
>> that it is the first two words of a command line that make up the
>> command's name (that is: for example, the effect of "git svn
>> dcommit" is described in git-svn(1)).
>
> Is this confusion really common?
>
> I can see how it might be possible in the case of a subcommand that
> itself has subcommands, but it seems less likely in the two examples you
> add below (where the third token is an option or a url). I like your
> "git svn" example better. Or "git remote" might be good.
>
> --b.
While I agree with the above, are we ready to talk about "git-svn"
or "git-remote" that early in the tutorial material?
We would want to mention the typesetting convention early in the manuals
(git(7), gittutorial(7) and user-manual.html) as well, so how about...
Conventions used in this document
---------------------------------
When talking about a git subcommand 'cmd', this documentation
typesets the name of it like 'git-cmd', and that is the name you
ask for its manual page.
Examples are typeset like this: `$ git cmd` (`$` is your command
prompt, do not actually type it to your shell). Note that a
subcommand is specified as the first parameter to the 'git'
program when you actually run it from the command line.
E.g. a typical command description may go like this:
To propagate the changes you made back to the original subversion
repository, you would use 'git-svn dcommit' command. It does
these things (long description here). Some examples:
------------
$ ... some example command sequence ...
$ git svn dcommit
------------
For full details, type:
------------
$ man git-svn
------------
^ permalink raw reply
* Re: [RFC/PATCH 7/7] Documentation formatting and cleanup
From: Junio C Hamano @ 2008-07-01 21:34 UTC (permalink / raw)
To: Olivier Marin; +Cc: Jonathan Nieder, git, Christian Couder, Jon Loeliger
In-Reply-To: <486A2C8C.5050204@free.fr>
Olivier Marin <dkr+ml.git@free.fr> writes:
> Also, in Documentation/gitdiffcore.txt, you did:
>
>> -These are applied in sequence. The set of filepairs git-diff-\*
>> +These are applied in sequence. The set of filepairs `git-diff-*`
>
> but the file does not compile, now.
There are other places with the same breakage.
You would need something like this (using the {asterisk} macro I
wrote for updating the docs for another topic). The patch shows only a
single use location but there are others in the same file.
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 10c1a15..40d43b7 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -8,6 +8,7 @@
# the command.
[attributes]
+asterisk=*
plus=+
caret=^
startsb=[
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 71568ab..7169eee 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -23,7 +23,7 @@ that are easier to understand than the conventional kind.
The chain of operation
----------------------
-The `git-diff-*` family works by first comparing two sets of
+The `git-diff-{asterisk}` family works by first comparing two sets of
files:
- `git-diff-index` compares contents of a "tree" object and the
^ permalink raw reply related
* Re: [PATCH] Teach "git apply" to prepend a prefix with "--root=<root>"
From: H. Peter Anvin @ 2008-07-01 20:27 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <1214935848.6619.1.camel@doriath>
Raimund Bauer wrote:
> On Tue, 2008-07-01 at 18:36 +0200, Johannes Schindelin wrote:
>>> There is an analogous concept in patch(1), it's just implemented by
>>> cd'ing to a subdirectory first. ;)
>> Hey, "--cd=" is free! And it would make explaining easier why -p is
>> applied first.
>
> patch uses -d or --directory
So it does.
-hpa
^ permalink raw reply
* Re: [StGit PATCH 03/14] Write to a stack log when stack is modified
From: Karl Hasselström @ 2008-07-01 20:13 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080617153247.GA12520@diana.vm.bytemark.co.uk>
On 2008-06-17 17:32:47 +0200, Karl Hasselström wrote:
> On 2008-06-17 15:11:42 +0100, Catalin Marinas wrote:
>
> > 2008/6/17 Karl Hasselström <kha@treskal.com>:
> >
> > > On 2008-06-17 11:24:53 +0100, Catalin Marinas wrote:
> > >
> > > > 2008/6/12 Karl Hasselström <kha@treskal.com>:
> > > >
> > > > > class _Directory(object):
> > > > > - def __init__(self, needs_current_series = True):
> > > > > + def __init__(self, needs_current_series = True, log = True):
> > > >
> > > > i.e. we make log = False here by default.
> > >
> > > I might not have understood precisely what you meant; but I
> > > don't think API backwards compatibilty should be an issue here?
> > > I simply fix all callers. If log should default to true or false
> > > is immaterial -- it just means some extra text in one or the
> > > other of two equally common cases.
> >
> > Not an issue, I just favour the existing one when the two cases
> > are almost equal.
>
> Fair enough. I'll change it.
I had an even better idea: no default value. Every caller gets to say
either log = True or log = False, which makes it immediately obvious
to the reader. (That is, every caller still using the old
infrastructure; with the new infrastructure, we log if and only if a
transaction is run.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC/PATCH 2/4] Add git-sequencer prototype documentation
From: Stephan Beyer @ 2008-07-01 19:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <200807012004.11563.jnareb@gmail.com>
Hi,
On Tue, Jul 01, 2008 at 08:04:10PM +0200, Jakub Narebski wrote:
> On Tue, 1 Jul 2008, Stephan Beyer wrote:
> > On Tue, Jul 01, 2008 at 06:02:54AM -0700,
> > Jakub Narebski <jnareb@gmail.com> wrote:
> >> Stephan Beyer wrote:
> >>> +merge [options] <commit-ish1> <commit-ish2> ... <commit-ishN>::
> >>> + Merge commits into HEAD.
> >>
> >> Nice.
> >>
> >> "HEAD" mean last picked up / created commit, isn't it?
> >
> > Right. This is used throughout the document...
> > I thought it is clear and better to use than always describing around it
> > by "last created commit".
>
> O.K.
I don't know. If something like "last created commit" is better,
I have no problem to change it :)
> >>> +ref <ref>::
> >>> + Set ref `<ref>` to the current HEAD, see also
> >>> + linkgit:git-update-ref[1].
> >>
> >> So this functions like "git reset --soft <ref>", isn't it?
> >
> > No. Why do you think that? `ref` is set, and not HEAD.
> > I think the description makes that clear.
>
> Ah. I'm sorry. So it is like "git branch <ref>", isn't it?
No. It is "git-update-ref <ref> HEAD".
> What is important is: does it update reflog (correctly)?
Good question. The reflog is another mistery to me that I haven't really
cared about, because I haven't used it yet myself.
At least the reflog test cases for git rebase -i in the test suite pass.
(Of course, this is only a weak indication that it works as it should.)
> >>> +squash [options] --from <mark>::
[...]
> > Here an example why it is useful for user-editing:
> >
> > (on commit f00babe)
> > mark :1
> > pick badcebab
> > patch foo
> > pick dadadada
> > squash -m "Foo the cebab" --signoff --from :1
> >
> > This squashes all between the mark and the squash into one commit,
> > on top of f00babe.
>
> Ah, so squash --from <mark> picks up everything since "mark <mark>",
> but does not include marked commit! Clever! In this case allowing
> only <mark> is a good idea, IMVHO.
Good, thanks :)
> >>> + --include-merges;;
> >>> + Sanity check does not fail if you have merges
> >>> + between HEAD and <mark>.
> >>
> >> How do you squash merges? Creating merge with an union of parents,
> >> excluding commits which got squashed?
> >
> > My squashes are realized using git reset --soft ... and then commit.
> > I think this makes only sense when there are no merges in between,
> > so I added the check, but if someone wants to squash merges, he should
> > be able to do it.
> >
> > To somehow answer your question: I do not care what the result is,
> > because I do not know what the result "should be".
>
> O.K. I guess that is something left for later, especially that
> forbidding merges in squashed commit is default (and you can always
> do without merges, I think).
Forbidding merges is default currently. It's just a sanity check. And
the option bypasses this check.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Junio C Hamano @ 2008-07-01 19:16 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Bruce Stephens, git
In-Reply-To: <20080701101414.GG31309@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * Bruce Stephens <bruce.stephens@isode.com> wrote:
> ...
>> It feels logical for "git status" to offer the same information (when
>> the information is appropriate).
>>
>> [...]
>
> i have a tip-curr (shortcut: 'tc') scriptlet to answer the "where I am
> amongst 100+ branches" question:
Perhaps like this, but be warned this is untested except for compilation
testing.
builtin-checkout.c | 39 +++++++++++++++++++++------------------
wt-status.c | 22 ++++++++++++++++++++++
2 files changed, 43 insertions(+), 18 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 93ea69b..2cbc39c 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -305,7 +305,7 @@ static int merge_working_tree(struct checkout_opts *opts,
return 0;
}
-static void report_tracking(struct branch_info *new, struct checkout_opts *opts)
+void report_tracking(FILE *fp, const char *name, struct commit *commit)
{
/*
* We have switched to a new branch; is it building on
@@ -321,7 +321,7 @@ static void report_tracking(struct branch_info *new, struct checkout_opts *opts)
int rev_argc;
int num_ours, num_theirs;
const char *remote_msg;
- struct branch *branch = branch_get(new->name);
+ struct branch *branch = branch_get(name);
/*
* Nothing to report unless we are marked to build on top of
@@ -339,7 +339,7 @@ static void report_tracking(struct branch_info *new, struct checkout_opts *opts)
return;
theirs = lookup_commit(sha1);
- ours = new->commit;
+ ours = commit;
if (!hashcmp(sha1, ours->object.sha1))
return; /* we are the same */
@@ -380,22 +380,25 @@ static void report_tracking(struct branch_info *new, struct checkout_opts *opts)
}
if (!num_theirs)
- printf("Your branch is ahead of the tracked%s branch '%s' "
- "by %d commit%s.\n",
- remote_msg, base,
- num_ours, (num_ours == 1) ? "" : "s");
+ fprintf(fp,
+ "Your branch is ahead of the tracked%s branch '%s' "
+ "by %d commit%s.\n",
+ remote_msg, base,
+ num_ours, (num_ours == 1) ? "" : "s");
else if (!num_ours)
- printf("Your branch is behind the tracked%s branch '%s' "
- "by %d commit%s,\n"
- "and can be fast-forwarded.\n",
- remote_msg, base,
- num_theirs, (num_theirs == 1) ? "" : "s");
+ fprintf(fp,
+ "Your branch is behind the tracked%s branch '%s' "
+ "by %d commit%s,\n"
+ "and can be fast-forwarded.\n",
+ remote_msg, base,
+ num_theirs, (num_theirs == 1) ? "" : "s");
else
- printf("Your branch and the tracked%s branch '%s' "
- "have diverged,\nand respectively "
- "have %d and %d different commit(s) each.\n",
- remote_msg, base,
- num_ours, num_theirs);
+ fprintf(fp,
+ "Your branch and the tracked%s branch '%s' "
+ "have diverged,\nand respectively "
+ "have %d and %d different commit(s) each.\n",
+ remote_msg, base,
+ num_ours, num_theirs);
}
static void update_refs_for_switch(struct checkout_opts *opts,
@@ -441,7 +444,7 @@ static void update_refs_for_switch(struct checkout_opts *opts,
remove_branch_state();
strbuf_release(&msg);
if (!opts->quiet && (new->path || !strcmp(new->name, "HEAD")))
- report_tracking(new, opts);
+ report_tracking(stdout, new->name, new->commit);
}
static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
diff --git a/wt-status.c b/wt-status.c
index 28c9e63..e02171a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -315,6 +315,26 @@ static void wt_status_print_verbose(struct wt_status *s)
run_diff_index(&rev, 1);
}
+/* NEEDSWORK */
+extern void report_tracking(FILE *fp, const char *name, struct commit *commit);
+
+static void wt_status_print_tracking(struct wt_status *s)
+{
+ unsigned char sha1[20];
+ struct commit *commit;
+
+ assert(s->branch && !s->is_initial);
+
+ if (prefixcmp(s->branch, "refs/heads/") ||
+ !resolve_ref(s->branch, sha1, 1, NULL))
+ return;
+ commit = lookup_commit(sha1);
+ if (!commit)
+ return;
+ fprintf(s->fp, "# ");
+ report_tracking(s->fp, s->branch + 11, commit);
+}
+
void wt_status_print(struct wt_status *s)
{
unsigned char sha1[20];
@@ -333,6 +353,8 @@ void wt_status_print(struct wt_status *s)
}
color_fprintf(s->fp, color(WT_STATUS_HEADER), "# ");
color_fprintf_ln(s->fp, branch_color, "%s%s", on_what, branch_name);
+ if (!s->is_initial)
+ wt_status_print_tracking(s);
}
if (s->is_initial) {
^ permalink raw reply related
* Re: How do I stop git enumerating my working directory
From: Brian Gernhardt @ 2008-07-01 19:01 UTC (permalink / raw)
To: Paul Gardiner; +Cc: git
In-Reply-To: <486A53CC.4020803@glidos.net>
On Jul 1, 2008, at 11:57 AM, Paul Gardiner wrote:
> I don't think I can make .gitignore files do the job, because
> it seems that you can set up to ignore a whole directory,
> and then partially countermand that by placing a .gitignore
> file (containing ! commands) inside the directory. That
> makes me think that ignoring doesn't prevent the
> enumeration.
That's where you're wrong. You can't get git to pay attention to
anything inside an ignored directory using the .gitignore files. Once
you ignore a directory, git stops looking at it completely. You can
force git to look at a file inside an ignored directory by adding it
directly, though. Git will pay attention to files you add for
changes, but won't pay any attention to other files around it.
See the log below for what I mean:
$ mkdir temp
$ cd temp
$ git init
Initialized empty Git repository in /Users/brian/dev/temp/.git/
$ cat > .gitignore
ignoredir/
$ mkdir ignoredir
$ touch A
$ touch ignoredir/B
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
# A
nothing added to commit but untracked files present (use "git add" to
track)
$ cat > ignoredir/.gitignore
!B
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
# A
nothing added to commit but untracked files present (use "git add" to
track)
$ git add ignoredir/B
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: ignoredir/B
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
# A
$ git commit -m "A"
Created initial commit 36ade7a: A
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 ignoredir/B
$ echo new > ignoredir/B
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: ignoredir/B
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
# A
no changes added to commit (use "git add" and/or "git commit -a")
^ permalink raw reply
* Re: [PATCH] Teach "git apply" to prepend a prefix with "--root=<root>"
From: Raimund Bauer @ 2008-07-01 18:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: H. Peter Anvin, Junio C Hamano, git
In-Reply-To: <alpine.LSU.1.00.0807011835090.32725@wbgn129.biozentrum.uni-wuerzburg.de>
On Tue, 2008-07-01 at 18:36 +0200, Johannes Schindelin wrote:
> > There is an analogous concept in patch(1), it's just implemented by
> > cd'ing to a subdirectory first. ;)
>
> Hey, "--cd=" is free! And it would make explaining easier why -p is
> applied first.
patch uses -d or --directory
regards,
Ray
^ permalink raw reply
* Re: [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits.
From: Björn Steinbrink @ 2008-07-01 18:01 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Junio C Hamano, git
In-Reply-To: <20080701100725.GE31309@elte.hu>
On 2008.07.01 12:07:25 +0200, Ingo Molnar wrote:
> There's a small detail i was thinking about: is there a way to get this
> extra output without actually switching branches? Right now i do this:
>
> earth4:~/tip> git-checkout tip; git-checkout master
> Checking out files: 100% (2437/2437), done.
> Switched to branch "tip"
> Switched to branch "master"
> Your branch is ahead of the tracked remote branch 'origin/master' by
> 50 commits.
>
> (Which is an admitted lame solution but the best i could figure.)
Just "git checkout" works for me:
git (master) $ git checkout
Your branch is behind the tracked remote branch 'origin/master' by 6 commits,
and can be fast-forwarded.
Björn
^ permalink raw reply
* Re: [RFC/PATCH 2/4] Add git-sequencer prototype documentation
From: Jakub Narebski @ 2008-07-01 18:04 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <20080701160322.GC5301@leksak.fem-net>
Hi,
On Tue, 1 Jul 2008, Stephan Beyer wrote:
> On Tue, Jul 01, 2008 at 06:02:54AM -0700,
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Stephan Beyer wrote:
>>>
>>> +git-sequencer will usually be called by another git porcelain, like
>>> +linkgit:git-am[1] or linkgit:git-rebase[1].
>>
>> I hope that it could be also used by git-cherry-pick and git-revert,
>> so it would be possible to pick more than one commit...
>
> Right, you've already mentioned it several times. ;-)
:blush: I'm sorry about that...
> But I haven't included it currently, because git-sequencer currently *uses*
> cherry-pick/revert to pick/revert commits, and I think this can lead to
> some confusion.
[...]
> So I'm only concentrating on rebase and am users until the builtin sequencer
> is in good shape.
Ah, I understand. It _is_ quite reasonable.
>>> +merge [options] <commit-ish1> <commit-ish2> ... <commit-ishN>::
>>> + Merge commits into HEAD.
>>
>> Nice.
>>
>> "HEAD" mean last picked up / created commit, isn't it?
>
> Right. This is used throughout the document...
> I thought it is clear and better to use than always describing around it
> by "last created commit".
O.K.
>>> +ref <ref>::
>>> + Set ref `<ref>` to the current HEAD, see also
>>> + linkgit:git-update-ref[1].
>>
>> So this functions like "git reset --soft <ref>", isn't it?
>
> No. Why do you think that? `ref` is set, and not HEAD.
> I think the description makes that clear.
Ah. I'm sorry. So it is like "git branch <ref>", isn't it?
What is important is: does it update reflog (correctly)?
>>> +squash [options] --from <mark>::
>>> + Squash all commits from the given mark into one commit.
>>> + There must not be any `merge` instructions between the
>>> + `mark` instruction and this `squash --from` instruction.
>>
>> Can you use <commit> instead of <mark> here?
>
> I wanted to make it clear that you can only specify a mark:
> a commit that has been somehow used in this sequencer session.
>
> Or have you meant that you think it is a bad restriction to only
> allow marks and no commits?
> I think this is a useful thing, because it's user-safe and I
> cannot imagine a case where you want to give a sha1 or a
> tag or branch or something.
>
> Here an example why it is useful for user-editing:
>
> (on commit f00babe)
> mark :1
> pick badcebab
> patch foo
> pick dadadada
> squash -m "Foo the cebab" --signoff --from :1
>
> This squashes all between the mark and the squash into one commit,
> on top of f00babe.
Ah, so squash --from <mark> picks up everything since "mark <mark>",
but does not include marked commit! Clever! In this case allowing
only <mark> is a good idea, IMVHO.
>>> + --include-merges;;
>>> + Sanity check does not fail if you have merges
>>> + between HEAD and <mark>.
>>
>> How do you squash merges? Creating merge with an union of parents,
>> excluding commits which got squashed?
>
> My squashes are realized using git reset --soft ... and then commit.
> I think this makes only sense when there are no merges in between,
> so I added the check, but if someone wants to squash merges, he should
> be able to do it.
>
> To somehow answer your question: I do not care what the result is,
> because I do not know what the result "should be".
O.K. I guess that is something left for later, especially that
forbidding merges in squashed commit is default (and you can always
do without merges, I think).
>>> +RETURN VALUES
>>> +-------------
>>> +* any other value on error, e.g.
>>> + running git-sequencer on a bare repository.
>>
>> Don't you enumerate those return values?
>
> In one of the very first spec versions, it was value 1, but:
[...]
> $ grep -m 1 -A 4 die_builtin usage.c
> static NORETURN void die_builtin(const char *err, va_list params)
> {
> report("fatal: ", err, params);
> exit(128);
> }
Perhaps stating that it returns 128 on fatal error, or rewording
that any other return value means some fatal error (does it?)
would be better. But that are details...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git push requires a subsequent git reset --hard ?
From: Jakub Narebski @ 2008-07-01 17:29 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0807010951j9e970f2k9624682b33c8af7d@mail.gmail.com>
"Neshama Parhoti" <pneshama@gmail.com> writes:
> I took with me a copy of a local repository to a week away from my station
> (just rsync'ed it to my laptop).
>
> On my return, I just "git push myuser@my-station:/my/git/repo" from my laptop.
> It seemed to work with no probs.
>
> On my station the git repo got the new commits, as I can see in
> git-log, but the actual files were left untouched.
>
> So I need to do something like "git reset --hard HEAD" to get
> the changes into the local files.
>
> Is that considered normal ?
This is considered normal. Push would never touch index nor working
area (although if you are the only user, and you know what you are
doing, you can add "git reset --hard HEAD" to post-receive hook). It
is the only way: "push" cannot be opposite of "pull" and do a merge
because there is nobody to resolve conflict on remote side.
So you should either do mirroring (1:1 refspec) push into bare
repository (without working directory), or push into remotes section,
remotes/satellite or remotes/mothership, like shown in GitFaq, below.
See also:
* "Why won't I see changes in the remote repo after "git push"?"
http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73
* "How would I use "git push" to sync out of a firewalled host?"
http://git.or.cz/gitwiki/GitFaq#head-46de97a5ac549d3adf406c22674b3325ae25d09c
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git push requires a subsequent git reset --hard ?
From: Jeff King @ 2008-07-01 17:19 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0807010951j9e970f2k9624682b33c8af7d@mail.gmail.com>
On Tue, Jul 01, 2008 at 07:51:26PM +0300, Neshama Parhoti wrote:
> On my return, I just "git push myuser@my-station:/my/git/repo" from my laptop.
> It seemed to work with no probs.
> On my station the git repo got the new commits, as I can see in
> git-log, but the actual files were left untouched.
>
> So I need to do something like "git reset --hard HEAD" to get
> the changes into the local files.
>
> Is that considered normal ?
>
> or did I do something wrong ?
See:
http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73
and
http://git.or.cz/gitwiki/GitFaq#head-46de97a5ac549d3adf406c22674b3325ae25d09c
What you did is OK, but there is a better way to do it.
-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