* Re: An alternate model for preparing partial commits
From: Dmitry Potapov @ 2008-06-28 4:03 UTC (permalink / raw)
To: Robert Anderson; +Cc: Git Mailing List
In-Reply-To: <9af502e50806271957o2df9e0abt9dadcb0514dd4173@mail.gmail.com>
On Fri, Jun 27, 2008 at 07:57:02PM -0700, Robert Anderson wrote:
> On Fri, Jun 27, 2008 at 7:14 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > On Fri, Jun 27, 2008 at 10:14:05AM -0700, Robert Anderson wrote:
> >>
> >> It is too subtle. That the index state - which becomes the next
> >> committed state - is not available for building or testing before
> >> committing is a deep flaw.
> >
> > And why is that? It is like saying that any editor that does not allow
> > you to compile the file without saving it first has a deep flaw.
>
> I don't believe it is like that. It would be like that if you
> intended for your on-tree disk to have a policy to always compile (for
> example). That is not a common use-case.
Do you think commit only tested changes is a common policy among
Git users? I seriously doubt that. And as I said before, git commit
is probably closer to saving a file than to what cvs commit does.
> > You can commit any changes
> > and amend them any time later before you publish your changes.
>
> This is enforcing a two-step process where there only need be one the
> vast majority of the time, to require that commit and publish be
> separate operations.
I don't see it is a problem. In fact, it saves time for me, because
I can work while tests are running, and considering the whole cycle
with different configurations may take 3 hours, I really want to do
something useful while it is running... Besides, I really believe
in review, so it cannot be one-step process anyway...
>
> > Those who care about quality should have a review process, and the
> > review process works best when all changes are slit in a small logical
> > steps. How do you propose to that without committing changes first?
>
> I don't understand the question.
If you use CVS like workflow, you may have the policy of no commit
until your patches are reviewed. In case of Git, you do commit but
only push to fast-forward only branch after receiving okay (or the
maintainer pull your changes to it). With Git, commit is more like
saving file, except that you save not a single file but the whole
changeset with the commit message and relevant information.
> > You can verify it, but you do that _after_ you committed changes but
> > before you publish them.
>
> Again, this is requiring two steps when it is otherwise not required,
> creating an inefficient workflow that is error prone.
I don't see why you think that is inefficient or error prone.
>
> > BTW, policy may include that it should be
> > compiled and tested on a few platforms, so you cannot do that in
> > your working directory anyway.
>
> Huh? I have done that every day for 15+ years.
You have your working directory let's say on Linux, and you have to
test your changes on Windows. So what do you do? With Git, it is
simple as you commit your changes and then run testing automatically
on different platforms and they use exactly what you put into the
repo. So if everything is okay, you can publish.
>
> > I think the source of your confusion is that you consider git commit
> > as cvs commit
>
> No. I have experience with a wide array of source control systems.
> CVS fits my mental model the least well. git is pretty close, but it
> is not there yet. The current partial commit facility is the biggest
> misfire, in my view.
Do you have your personal experience of using it, or it is just some
abstract considerations? Certainly, any feature may be misused but, in
general, it is handy and I have not had any problem with it. And, yes,
if I split a very complex patch then I will use stash to facilitate
me with this work, but it is rare.
> I like that git's philosophy does not include a draconian policy of
> not changing history. That's fine, it's practical, and it's useful,
> to cover common scenarios in which you'd like to quickly recover from
> a mistake. However, I am afraid that these facilities have been
> abused and turned into something that they are not well-suited for,
> i.e., the use of lines of development as both keepers of history and
> of scratch spaces where you scribble around with temporary things, all
> the while git having no clue which is intended.
I don't see why git should know it. The policy depends on workflow
and is usually enforced by hooks. I don't see why Git should care
about it deeply. It is like a word processor can be used for writing
a draft of a document or the final version for publication. Sure,
you can mark something as work-in-progress (use tags or comments),
but it is not something about Git should care deeply inside.
Dmitry
^ permalink raw reply
* Re: bug related to branches using / in name
From: Jeff King @ 2008-06-28 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon Holm Thøgersen, git, Ingo Molnar
In-Reply-To: <7vtzfemp4d.fsf@gitster.siamese.dyndns.org>
On Fri, Jun 27, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:
> >> It might be nicer if this were handled automatically, but it would
> >> violate git-fetch's rule about never deleting branches.
>
> Hmm. Is there actually such a rule?
I thought so, though I don't necessarily agree with it. But I seem to
recall this being touted as a feature in the past; a remote deleting
some work will not cause it to be deleted locally.
> I was wondering if it might make more sense to do the equivalent of what
> checkout_entry() does (i.e. remove_subtree()) when there is such a
As as long your "equivalent of" means "branch -d"; we need to kill off
both the ref and its reflogs. And therefore...
> conflict. After all, tracking branches are meant to accept rewinds and
> anything that happens on the remote end, and having to run "git remote
> prune" is not a feature but is a lack of feature in the "git fetch", which
> may make it look like deletion is somewhat special.
The one key difference between rewinds and branch deletion is that the
latter will kill off the reflog, making the history inaccessible. You
can always still access rewound or rebased work via the reflog.
If we don't care about this "safety feature", then I definitely agree
that we should fix the problem rather than hint to the user.
-Peff
^ permalink raw reply
* Re: [PATCH] fetch: report local storage errors in status table
From: Jeff King @ 2008-06-28 4:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon Holm Thøgersen, git, Ingo Molnar
In-Reply-To: <7vprq2moua.fsf@gitster.siamese.dyndns.org>
On Fri, Jun 27, 2008 at 04:37:33PM -0700, Junio C Hamano wrote:
> > With this patch, the output takes into account the status of
> > updating the local ref:
> >
> > error: there are still refs under 'refs/remotes/origin/foo'
> > From $url_of_repo
> > ! [new branch] foo -> origin/foo (unable to update local ref)
>
> Makes sense --- thanks. This is something we can have automated tests,
> isn't it?
We don't currently have any tests for either the fetch output or the
push output. Note that we aren't changing the output _status_. Fetch
always knew that this condition was a failure, and exited appropriately.
So it really would just be testing the expected human-readable output in
these situations, something I thought we usually didn't include in the
tests.
But if you think it is worth doing, I can whip up a few tests.
-Peff
^ permalink raw reply
* [PATCH resend] help: check early if we have a command, if not try a documentation topic
From: Christian Couder @ 2008-06-28 4:35 UTC (permalink / raw)
To: Junio Hamano, Pieter de Bie, Jakub Narebski; +Cc: git
Before this patch, something like "git help tutorial" did not work,
people had to use "git help gittutorial" which is not very intuitive.
This patch uses the "is_git_command" function to test early if the
argument passed to "git help" is a git command, and if this is not the
case then we prefix the argument with "git" instead of "git-".
This way, things like "git help tutorial" or "git help glossary" will
work fine.
The little downside of this patch is that the "is_git_command" is a
little bit slow.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
help.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
The only change since the previous patch is that I removed
the following line after the 2 strcpy:
p[pre_len + cmd_len] = 0;
because it is useless.
diff --git a/help.c b/help.c
index 6c16fb4..1f990b9 100644
--- a/help.c
+++ b/help.c
@@ -550,20 +550,26 @@ static int is_git_command(const char *s)
is_in_cmdlist(&other_cmds, s);
}
+static const char *add_prefix(const char *prefix, const char *cmd)
+{
+ size_t pre_len = strlen(prefix);
+ size_t cmd_len = strlen(cmd);
+ char *p = xmalloc(pre_len + cmd_len + 1);
+ strcpy(p, prefix);
+ strcpy(p + pre_len, cmd);
+ return p;
+}
+
static const char *cmd_to_page(const char *git_cmd)
{
if (!git_cmd)
return "git";
else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
- else {
- int page_len = strlen(git_cmd) + 4;
- char *p = xmalloc(page_len + 1);
- strcpy(p, "git-");
- strcpy(p + 4, git_cmd);
- p[page_len] = 0;
- return p;
- }
+ else if (is_git_command(git_cmd))
+ return add_prefix("git-", git_cmd);
+ else
+ return add_prefix("git", git_cmd);
}
static void setup_man_path(void)
--
1.5.6.1.202.g316c4.dirty
^ permalink raw reply related
* Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.
From: Jeff King @ 2008-06-28 4:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vfxr0sj61.fsf@gitster.siamese.dyndns.org>
On Thu, Jun 26, 2008 at 01:19:02AM -0700, Junio C Hamano wrote:
> That "strict rewind" workaround alone made me so disgusted beyond words.
Heh.
> And if you do not want to trigger "what you are pushing is not up to
> date", the solution is simple. You do not push them.
>
> I however think what Pierre wanted to do is different, and you do not have
> to solve "force this strict rewind" problem to solve it.
>
> What we need is (with a configuration option) to change the meaning of
> "matching refs" from the current definition "branches with the same name
> between here and there" to "branches with the same name between here and
> there, but excluding the ones that do not fast forward (or strictly
> behind)". So if you have tons of stale branches you checked out but
> haven't touched most of them, your "matching push" won't even try to push
> what you haven't touched.
OK. Isn't this basically just another way of restating my third
"solution"? Mine marks strict rewinds as "up to date" instead of
"matching", but in either case, the result is that there is nothing to
even try pushing. And the proposal I gave was "allow -f to force a
strict rewind [which would be as it is now] but only if the refspec is
mentioned explicitly on the command line, and not part of an automatic
match."
So I think the behavior is the same, but the difference is the mental
model.
And not counting stale branches as matching doesn't seem like quite the
right mental model. The matching is about the ref _names_, not about
their contents. So I think the better mental model is that these
branches are simply "up to date" already -- the remote has everything we
have, and more.
Not to mention that ref matching can affect _other_ refs, too, can it
not? I think there are some checks for having two refspec srcs pushing
to the same dest.
> I do not think we would ever want to allow a configuration that disables
> the exit status from push upon a push failure when somebody explicitly
> says "git push $there $this" and $this is not non-fast-forward. If you
> asked $this to be pushed, and if $this cannot be pushed, we _should_ error
> out.
We do this already for refs that have no changes to push. IOW, we are
not masking an error so much as saying "this condition is _not_ an
error" (and letting the user say that with a config option).
> (1) when you say "git push" to trigger the "matching refs" push, with the
> new configuration, you do not error out nor even try to push out
> things that do not fast forward. Pretend that you did not even
> attempt to push them, and do not error out. This may result in not
> pushing anything out, but that is what the people who have such a
> configuration is asking for.
>
> If you have configured which branches are pushed when you are on your
> current branch, and that branch --- most likely it is that current
> branch --- does not fast forward, it is your problem.
>
> (2) even with such a configuration, you can "git push $there $this" and
> "git push $there +$this" to explicitly ask refs to be pushed. Such a
> push won't be interfered by the new configuration and correctly fail
> (or force).
I think (1) should be implemented not as "this src ref and this dst ref
do not match" but rather "this pair is up to date". And given that, I
think that is basically the same as my proposal, except that the
"push.rewindIsUpToDate" config variable would only be respected for a
"matching refs" push. Which does feel a little inconsistent, as I noted
in my previous mail, but I think it DWYM.
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.
From: Jeff King @ 2008-06-28 4:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <20080628043338.GC9451@sigill.intra.peff.net>
On Sat, Jun 28, 2008 at 12:33:38AM -0400, Jeff King wrote:
> I think (1) should be implemented not as "this src ref and this dst ref
> do not match" but rather "this pair is up to date". And given that, I
> think that is basically the same as my proposal, except that the
> "push.rewindIsUpToDate" config variable would only be respected for a
> "matching refs" push. Which does feel a little inconsistent, as I noted
> in my previous mail, but I think it DWYM.
Where of course if we take "Y" in DWYM to be Pierre, he has already said
that's what he meant. :)
-Peff
^ permalink raw reply
* Re: bug related to branches using / in name
From: Junio C Hamano @ 2008-06-28 4:57 UTC (permalink / raw)
To: Jeff King; +Cc: Simon Holm Thøgersen, git, Ingo Molnar
In-Reply-To: <20080628041841.GA9451@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> As as long your "equivalent of" means "branch -d"; we need to kill off
> both the ref and its reflogs. And therefore...
> ...
> The one key difference between rewinds and branch deletion is that the
> latter will kill off the reflog, making the history inaccessible. You
> can always still access rewound or rebased work via the reflog.
Hmm, you are right.
I somehow still had a vague distant memory from late 2006 when we did not
have reflogs for remotes/ hierarchy.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Jeff King @ 2008-06-28 5:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Robert Anderson, Git Mailing List
In-Reply-To: <7vprq2rbfz.fsf@gitster.siamese.dyndns.org>
On Fri, Jun 27, 2008 at 11:15:44AM -0700, Junio C Hamano wrote:
> I've always said that I am not in favor of any form of partial commits,
> exactly for the reason Robert states, namely that you are not committing
> what you had in your work tree as a whole. I said so back when the only
> form of partial commits were "git commit [-o] this-file". I said it again
> even when I introduced "add -i", that the interface goes backwards and
> does not fix the issues associated with partial commits.
I do partial commits all the time. I used to use the "go back and clean
up and test each" method. But now with stash, I use the workflow
mentioned elsewhere in the thread:
1. hack hack hack
2. add -i; commit -m tmp
3. stash
4. reset HEAD^
which is really kind of awkward, since I didn't want to make that commit
in the first place.
I think of it as three ordered buckets: index, working tree, and stash.
You can move changes from any bucket to an adjacent bucket, but you can
only test what's in the working tree.
So we have too many changes in the working tree. Right now we can put
some of them in the index bucket. But that doesn't help with testing.
So what I do now is move good changes to the index bucket (and then
commit -- more on that in a second), and then everything else to the
stash bucket, and then reset the commit.
The extra commit / reset is annoying. We could do better than that
with the proposed "stash --keep-index". Then I just have to move my good
changes into the index and say "ok, now stash everything else."
But that still involves two bucket moves. I think what would be much
more natural is to simply say "I don't want these changes right now;
move them into the stash bucket." And Dscho mentioned "git stash -i",
which does that (and theoretically, it could even be based on the "git
add -i" code).
What you propose below accomplishes the same thing, but seems mentally
reversed to me (and involves two bucket moves):
> One thing I think would make sense is to stash away _everything_ at this
> point. That would take you to the state before you started working. Then
> if we can selectively _unstash_ the parts that should logically be
> committed first to bring them to your work tree, then you can inspect that
> change against HEAD, test it, and when you are happy with it, you would
> make your first commit in the final sequence.
Here we say "OK, I don't want any of these changes; stash them" and then
selectively bring them back. And maybe that _is_ what you want
sometimes, or maybe how certain people think. But personally, given two
sets of changes, what makes sense to me is to directly say "these are
the changes I _don't_ want". And at any point after ditching some
changes, you can re-run your tests.
So I fundamentally think that all of these contortions are because
moving things to the stash bucket is not as featureful as moving them to
the index bucket. And there's no reason for it, since we can use the
_same_ tools to do both.
Here's a somewhat hackish implementation of "git stash -i" that just relies
on "add -i":
---
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..6685004 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -67,7 +67,7 @@ create_stash () {
GIT_INDEX_FILE="$TMP-index" &&
export GIT_INDEX_FILE &&
git read-tree -m $i_tree &&
- git add -u &&
+ git add $ADD_OPTIONS </dev/tty >/dev/tty 2>&1 &&
git write-tree &&
rm -f "$TMP-index"
) ) ||
@@ -218,6 +218,11 @@ drop_stash () {
git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
}
+ADD_OPTIONS="-u"
+case "$1" in
+ -i|-p) ADD_OPTIONS=$1; shift
+esac
+
# Main command set
case "$1" in
list)
@@ -235,7 +240,7 @@ show)
;;
save)
shift
- save_stash "$*" && git-reset --hard
+ save_stash "$*" && show_stash -p -R | git apply
;;
apply)
shift
@@ -269,7 +274,7 @@ pop)
then
save_stash &&
echo '(To restore them type "git stash apply")' &&
- git-reset --hard
+ show_stash -p -R | git apply
else
usage
fi
^ permalink raw reply related
* Re: Make test on AIX
From: Jeff King @ 2008-06-28 5:15 UTC (permalink / raw)
To: Craig L. Ching; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302389D09@emailmn.mqsoftware.com>
On Fri, Jun 27, 2008 at 04:13:41PM -0500, Craig L. Ching wrote:
> The first thing I encountered was that because the tests all use
> #!/bin/sh the exit code was not what the tests expected. So I ended up
> running 'make SHELL=`which bash` all' directly in the git/t/ directory.
> That seemed to shake out and work for most of the tests except for
> t/t7502-commit.sh. Try as I might, I could not get SHELL_PATH set to
> anything but /bin/sh except to hard-code the SHELL_PATH in this script.
The SHELL_PATH actually comes from the build options for all of git. So
you should be able to go to the toplevel of your git repo and do a "make
SHELL_PATH=`which bash`". This means that we will also use bash for all
of the script components of git.
I don't know how necessary that is on AIX, but it certainly is on
Solaris, where /bin/sh is unusable.
-Peff
^ permalink raw reply
* Fwd: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 6:31 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9af502e50806272320p23f01e8eo4a67c5f6f4476098@mail.gmail.com>
On Fri, Jun 27, 2008 at 9:03 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> Do you think commit only tested changes is a common policy among
> Git users?
I think there are various flavors of "tested" for which the answer is
certainly yes. I think that a line of development which always
builds, for example, is very, very common.
> And as I said before, git commit
> is probably closer to saving a file than to what cvs commit does.
That is putting scm into the development process at a level which is
far too intrusively fine-grained for my workflow, and for the workflow
of any developer that I work with, which is dozens. I do not need to
record every "save of file." That is useless and intrusive to me. It
is, however, useful to me to record (commit) at points significantly
more coarse grained than that: points which represent logically
distinct changes to the code that compile, for example. Until then I
prefer to forget about my scm and have it stay out of my way until it
is needed to create those desired recorded states.
>> This is enforcing a two-step process where there only need be one the
>> vast majority of the time, to require that commit and publish be
>> separate operations.
>
> I don't see it is a problem.
Fine, you like doing extra work for no benefit. Enjoy yourself.
> I don't see why you think that is inefficient or error prone.
Plainly not. This is why I will construct some examples.
> You have your working directory let's say on Linux, and you have to
> test your changes on Windows. So what do you do?
I rebuild on about a dozen platforms simultaneously on a cross-mounted disk.
>> No. I have experience with a wide array of source control systems.
>> CVS fits my mental model the least well. git is pretty close, but it
>> is not there yet. The current partial commit facility is the biggest
>> misfire, in my view.
>
> Do you have your personal experience of using it
Yes.
> I don't see why git should know it.
Clearly not. Example 1: is it ok to publish? If temporary commits
exist, git should stop you. But git has no idea if temporary commits
exist or not.
Bob
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 7:03 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <20080628050317.GE9451@sigill.intra.peff.net>
On Fri, Jun 27, 2008 at 10:03 PM, Jeff King <peff@peff.net> wrote:
> So I fundamentally think that all of these contortions are because
> moving things to the stash bucket is not as featureful as moving them to
> the index bucket. And there's no reason for it, since we can use the
> _same_ tools to do both.
>
> Here's a somewhat hackish implementation of "git stash -i" that just relies
> on "add -i":
Are all features for moving changes to stash bi-directional in your
implementation? Can we move a hunk out of stash, just as easily as we
can move one in? I think this is an essential property of a good
implementation of this workflow.
As to which way people like to think and work, in terms of re-applying
changes from a fresh state one at a time, or just pushing off changes
they don't want, I think ensuring bi-directionality in the tools for
moving changes back and forth will ensure that all such scenarios will
be equally well supported.
It does seem to me at this point that extending stash functionality is
a reasonable way to approach supporting this type of workflow.
Thanks,
Bob
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Jeff King @ 2008-06-28 8:53 UTC (permalink / raw)
To: Robert Anderson; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <9af502e50806280003p59d00444hd1914a28a3a71d7e@mail.gmail.com>
On Sat, Jun 28, 2008 at 12:03:54AM -0700, Robert Anderson wrote:
> > Here's a somewhat hackish implementation of "git stash -i" that just relies
> > on "add -i":
>
> Are all features for moving changes to stash bi-directional in your
> implementation? Can we move a hunk out of stash, just as easily as we
> can move one in? I think this is an essential property of a good
> implementation of this workflow.
No, they're not bi-directional. You get the full power of "add -i" when
moving things into the stash, but not out. It is the reverse of the
situation with the index; we have good tools for staging things, but not
for unstaging them.
But I agree that they _should_ be. Given the patch I posted already,
probably the simplest way to do both at once would be to give "add -i"
an "unstage" mode.
> It does seem to me at this point that extending stash functionality is
> a reasonable way to approach supporting this type of workflow.
Actually, I oversimplified a little bit in my "buckets" description.
Stash actually stashes two things: the current index and the current
worktree. So in that sense, it is not just another bucket as I
described. For the purposes of the workflow we're discussing, I think
that is how we want it to function. But the implementation will be a bit
trickier than it might otherwise be because of this. I just didn't want
to have to introduce another, slightly different type of stash.
-Peff
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Stephen R. van den Berg @ 2008-06-28 9:30 UTC (permalink / raw)
To: David Jeske; +Cc: Stephen Sinclair, Git Mailing List
David Jeske wrote:
>- I could supercede 2-commits with 1, effectively making the bad-commit
>disappear in the linear history. Users who already have the history, however,
>would be unaffected, because the start/end endpoints are the same.
Superseding does not work in git trees and is a disruptive operation to
*all* commits following the point being superseded.
Also, superseding preserves the startpoint, but *always* alters the
endpoint.
I suggest you take a look at how a git-repository is stored and learn
about how the SHA1-hashes interact with the stored repository.
--
Sincerely,
Stephen R. van den Berg.
Heisenberg might have been here.
^ permalink raw reply
* Re: bug related to branches using / in name
From: Jakub Narebski @ 2008-06-28 11:42 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Simon Holm Thøgersen, git, Ingo Molnar
In-Reply-To: <20080628041841.GA9451@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Jun 27, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:
>>
>> [...] After all, tracking branches are meant to accept rewinds and
>> anything that happens on the remote end, and having to run "git remote
>> prune" is not a feature but is a lack of feature in the "git fetch", which
>> may make it look like deletion is somewhat special.
>
> The one key difference between rewinds and branch deletion is that the
> latter will kill off the reflog, making the history inaccessible. You
> can always still access rewound or rebased work via the reflog.
>
> If we don't care about this "safety feature", then I definitely agree
> that we should fix the problem rather than hint to the user.
There were some attempts to add some kind of "Attic" to save
reflogs for deleted branches, but IIRC the discussion petered out
after few initial patches because there were some conflict over
details of implementation (the problem being how to deal with D/F
conflicts).
If this makes into git, this trouble will disappear... perhaps
with some stronger marker that branches can dissapear, not only
rewind
+!refs/heads/*:refs/remotes/origin/*
or
+refs/heads/*?:refs/remotes/origin/*?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Adding a 'version' command to the server (was: git@vger.kernel.org)
From: Alex Riesen @ 2008-06-28 11:43 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Junio C Hamano, git
In-Reply-To: <486572BC.9070201@gmail.com>
Lea Wiemann, Sat, Jun 28, 2008 01:07:40 +0200:
> Junio C Hamano wrote:
>> It is still possible to connect to older remote end with new clients, but
>> you have to explicitly ask for "git-upload-pack" by using --upload-pack=
>> option when running "git fetch"
>
> Now that the current git won't work with older servers anyway, what
> about using this opportunity to add a 'version' command to the server?
> With such a command, such problems would seem to be quite easily
> avoidable in the future, since the client can discriminate based on the
> server's version.
And exactly how are the incompatibility problems avoided? By denying
the service if the versions don't match?
^ permalink raw reply
* Re: Ramifications of a git-sh-setup outside the PATH
From: Alex Riesen @ 2008-06-28 12:01 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20080627140027.BIA12244@m4500-01.uchicago.edu>
Jonathan Nieder, Fri, Jun 27, 2008 21:00:27 +0200:
> Hi gitsters,
>
> I noticed in the release notes to Git 1.6.0 that dashed-form commands
> are moving to a libexecdir outside the PATH. I have been using Git
> with nd/dashless applied for about a month, and it does work well
> (thanks!). There was one little glitch: to use hg-fast-export.sh from
> fast-export.git (of repo.or.cz), I had to put git-sh-setup in the PATH.
>
> I wanted to just change the ". git-sh-setup" line to ". git sh-setup",
> but of course that will not work. Am I missing something?
Try
. "$(git --exec-path)/git-sh-setup"
"git-sh-setup" is not a command, but a Bourne Shell script you can use
in your scripts by including it. So ". git sh-setup" just tries to
_include_ file "git" (and will try $PATH and current directory) with
positional argument "sh-setup" (see man 1 bash, for example).
^ permalink raw reply
* Re: Adding a 'version' command to the server
From: Lea Wiemann @ 2008-06-28 12:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20080628114337.GA3489@steel.home>
Alex Riesen wrote:
> And exactly how are the incompatibility problems avoided? By denying
> the service if the versions don't match?
No, by talking to older servers in a way they understand it. So for
instance it would call "git-upload-pack" instead of "git upload-pack".
(See also the SSH protocol with two versions, and I think Subversion's
svnserve also somehow identifies its own capabilities and/or version.)
-- Lea
^ permalink raw reply
* Re: Fwd: An alternate model for preparing partial commits
From: Dmitry Potapov @ 2008-06-28 12:38 UTC (permalink / raw)
To: Robert Anderson; +Cc: Git Mailing List
In-Reply-To: <9af502e50806272331vfdbf35ap10fc4375518de946@mail.gmail.com>
On Fri, Jun 27, 2008 at 11:31:24PM -0700, Robert Anderson wrote:
> On Fri, Jun 27, 2008 at 9:03 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > Do you think commit only tested changes is a common policy among
> > Git users?
>
> I think there are various flavors of "tested" for which the answer is
> certainly yes. I think that a line of development which always
> builds, for example, is very, very common.
Well, I don't think it is very common. Almost always builds, yes. As I
said before, with Git commit means more like saving your changes in
logical steps. Making sure that they are good enough to be publish is
done later, and it usually includes testing and may include something
else like code review, and code review is much easier if your work is
recorded in small logical steps, and when you can share these changes
easily and continue your normal work while your changes are reviewed.
> >> This is enforcing a two-step process where there only need be one the
> >> vast majority of the time, to require that commit and publish be
> >> separate operations.
> >
> > I don't see it is a problem.
>
> Fine, you like doing extra work for no benefit. Enjoy yourself.
I don't see where you find this extra work. Maybe, pressing a button
to save the file is also extra work? As to benefit, they are real for
me as it saves a lot of time and allows me to work more natural, in
the same way as you edit document. Your first version of document
does not have to be perfect, you can review and improve it later,
instead you focus on main ideas you want to express, and later, you
will proofread and rearrange things, but it is very important to
being able to save your changes even if they are not perfect yet.
Extra work like pressing the save button is negligible comparing
to everything else.
> > You have your working directory let's say on Linux, and you have to
> > test your changes on Windows. So what do you do?
>
> I rebuild on about a dozen platforms simultaneously on a cross-mounted disk.
Does it work for MS Visual Studio? The last time I tried, it did not
allow to build the project on a shared disk. Anyway, your compilation
time is going to be worse due to network latency, and simultaneously
building on different platforms will be more difficult to organize.
With Git, you get everything for free. You committed your changes
and they immediately available everywhere, and when all tests passed
you can push changes to the main branch, or send to the integrator a
request to pull, or to send a request to code review. It all depends
on your policy...
> > I don't see why git should know it.
>
> Clearly not. Example 1: is it ok to publish? If temporary commits
> exist, git should stop you. But git has no idea if temporary commits
> exist or not.
There are no such thing as temporary commits in Git. There are changes
that are ready to be accepted to the main branch and those that are not.
It could be different reasons why these changes cannot be integrated to
the main branch now. Maybe, you should receive feedback from someone
who does code review your changes. Maybe, these changes deem too risky
to be integrated now. Maybe, they will clash with someone else's work,
which has a higher priority, maybe something else. So, I don't see how
you expect Git to know all of that. It is like to expect that your word
processor to know what whether your document is good work publication or
not, and don't let you to send the document out if it is not.
Dmitry
^ permalink raw reply
* Re: [EGIT PATCH 20/23] Push command line utility
From: Robin Rosenberg @ 2008-06-28 12:36 UTC (permalink / raw)
To: Marek Zawirski; +Cc: spearce, git
In-Reply-To: <1214604407-30572-21-git-send-email-marek.zawirski@gmail.com>
Marek,
RefSpecs are unmutable classes. I Can squeeze this into the patchset.
Other than that, impressive!
-- robin
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Push.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/Push.java
index 4130bc9..cbdf465 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/pgm/Push.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Push.java
@@ -104,9 +104,9 @@ class Push extends TextBuiltin {
transport.setOptionReceivePack(exec);
for (; argi < args.length; argi++) {
- final RefSpec spec = new RefSpec(args[argi]);
+ RefSpec spec = new RefSpec(args[argi]);
if (forceAll)
- spec.setForceUpdate(true);
+ spec = spec.setForceUpdate(true);
refSpecs.add(spec);
}
final Collection<RemoteRefUpdate> toPush = transport
^ permalink raw reply related
* Re: [PATCH, next version] git bisect: introduce 'fixed' and 'unfixed'
From: Johannes Schindelin @ 2008-06-28 13:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vprq2o4zb.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 27 Jun 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When you look for a fix instead of a regression, it can be quite hard
> > to twist your brain into choosing the correct bisect command between
> > 'git bisect bad' and 'git bisect good'.
>
> Hmm, I do not currently see any differene between master and next version
> of bisect. In what way is this 'next' version?
It has a "BAD" and a "GOOD" variable that are reset to "fixed" and
"unfixed" if the user said "fixed" or "unfixed".
> Aside from the 'visualize' issue this does not attempt to address,
Yes, I forgot about that issue, mainly because I do not use it myself...
> I wonder if it may be a good idea to detect and warn mixed usage as well
> (e.g. "You earlier said 'bad' but now you are saying 'fixed' -- are you
> sure?"), and if so if it can be implemented easily.
Hmm. I tried to avoid that, as it would mean a larger patch. But I guess
you could write .git/BISECT_TERMS or some such.
But that, together with the visualize part, would take more time than I am
willing to spend on this issue.
Well, I guess I'll leave it then,
Dscho
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Stephen Sinclair @ 2008-06-28 14:34 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9af502e50806271708p7979ae65k61b71be90efff2c4@mail.gmail.com>
On Fri, Jun 27, 2008 at 8:08 PM, Robert Anderson <rwa000@gmail.com> wrote:
> If I come back to a branch on which there are several
> commits which have not been pushed yet, how do I know which are
> "temporary" and which are "for real" commits? I cannot. It is
> impossible. The information is not there.
I use the comments for this. I frequently have comments that say...
"NOT FINISHED, AMEND this". I make sure they don't get into my public
repo.
You could even automate it with a hook. You could program your public
repo to refuse a push that contains commits with some keyword like
"WIP", and get used to putting WIP into any new commit until you're
sure about it. I think you can even program a hook (commit-msg?) to
generate the initial comment for any commit, so you could make it the
default.
> But, all of this is moot when you consider the simple case of a repo
> which has been cloned, on which you'd like to make partial commits,
> and test the committed state before doing so.
You can work in a branch which is not intended to be cloned, and only
merge/rebase to master when you're ready. You can work in a separate
repo and only push to public when you're ready. There are several
solutions here for what you want to do.
The answer is simple: you should not be making partial commits to a
repo that has been cloned. You should instead be working somewhere
else and then pushing to it. So this whole sentence is just a moot
point itself.
Steve
^ permalink raw reply
* Git usage for bk-user
From: Jonas Oreland @ 2008-06-28 13:36 UTC (permalink / raw)
To: git
Hi,
How do I "bk changes -L <other repo>" in Git ?
I think I can set this up for repos/branches i "normally" track,
but if <other repo> is something which I access infrequently.
Do I still new "git-remote..."
Also, is there a "git-for-bk-dummies" guide somewhere?
I asked mr. google wo/ finding anything...
/Jonas
^ permalink raw reply
* Patches for qgit on MacOS X
From: Olivier Croquette @ 2008-06-28 14:52 UTC (permalink / raw)
To: git
Hi all
I have posted 2 patches against qgit to make it work (better) under MacOS X:
http://sourceforge.net/tracker/index.php?func=detail&aid=2005126&group_id=139897&atid=744829
http://sourceforge.net/tracker/index.php?func=detail&aid=2005125&group_id=139897&atid=744829
Comments are welcome.
When they are integrated, I will create a MacPorts port for even easier
installation for Mac users.
Best regards
Olivier
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Johannes Schindelin @ 2008-06-28 14:51 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20080628050317.GE9451@sigill.intra.peff.net>
Hi.
On Sat, 28 Jun 2008, Jeff King wrote:
> Here's a somewhat hackish implementation of "git stash -i" that just
> relies on "add -i":
I like it.
> +ADD_OPTIONS="-u"
> +case "$1" in
> + -i|-p) ADD_OPTIONS=$1; shift
> +esac
I'll squash in "|-e" here.
Note that some time ago, I was working on "git stash apply -i", which I
never came around to finish. Yesterday, I was briefly considering working
on it, but I have other things to tend to now.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] shrink git-shell by avoiding redundant dependencies
From: Johannes Schindelin @ 2008-06-28 14:51 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Git Mailing List
In-Reply-To: <1214602538-7888-1-git-send-email-dpotapov@gmail.com>
Hi,
On Sat, 28 Jun 2008, Dmitry Potapov wrote:
> A lot of modules that have nothing to do with git-shell functionality
> were linked in, bloating git-shell more than 8 times.
/me wonders if "strip git-shell" would not take care of all that.
Just curious,
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