* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Jay Soffian @ 2011-10-05 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, nicolas.dichtel
In-Reply-To: <7v8voz8hgq.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Pinging Jay who may have know a thing or two from the history leading to
> 37f7a85 (Teach commit about CHERRY_PICK_HEAD, 2011-02-19).
Yep, I replied to Nicolas' other message.
j.
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Jeff King @ 2011-10-05 17:55 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4E8B5553.2080706@drmicha.warpmail.net>
On Tue, Oct 04, 2011 at 08:49:55PM +0200, Michael J Gruber wrote:
> We seem to mean something different:
>
> git config --get remote.bitbucket.pushurl
> https://grubix@bitbucket.org/grubix/git.git
> SSH_ASKPASS= git push -n bitbucket
> Username for 'bitbucket.org':
>
> I mean that git should not need to ask for the username here.
No, we are in agreement about the intended behavior. I think you are
seeing a bug. What version of git produced it?
With my http-auth series, I get:
$ git push https://github.com/peff/git.git
Username for 'github.com':
$ git push https://peff@github.com/peff/git.git
Password for 'github.com':
Using v1.7.7 produces similar results.
-Peff
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Gioele Barabucci @ 2011-10-05 17:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7vd3eb8hkb.fsf@alter.siamese.dyndns.org>
On 05/10/2011 19:38, Junio C Hamano wrote:
>> In fact the support for gitattributes using patterns involving "." was
>> pretty spotty in v1.7.6 too. For example,
>
> The attribute patterns (or exclude patterns for that matter) were never
> designed to name "the current directory". The way to name "everything *in*
> this directory" has always been to say "*" (the "* text=auto" example in
> the documentation says it shows how to set the attribute "for all
> files"). Admittedly the pattern may miss ".*" files.
What if I do not want to say things about the "content" of the directory
but about the directory itself? This is exactly my case.
> I have to agree that things like "./" and "." were outside the scope of
> the design; in some cases undefined behaviour given to such patterns may
> have made sense but that was mere accident.
Actually what I have in my `~/.gitattributes` is
/. show_in_prompt=no
Anyway, I see a conflict between
> - A leading slash matches the beginning of the pathname.
> For example, "/{asterisk}.c" matches "cat-file.c" but not
> "mozilla-sha1/sha1.c".
and
> - If the pattern is a single dot and nothing else, it matches everything
> in the current directory.
in the first case `.` is treated as a "glob dot", while in the second
case it is treated as a "regexp dot". I would find this confusing.
Patterns can match directories using `/foo`. Why don't you just say that
`.` is equivalent to `./` and `/foo/.` is equivalent to `/foo`?
> So "./" in .gitignore or .gitattributes at the toplevel would match all
> the top-level directories and files but does not apply to the paths
> contained in the matched directories. "." in .gitignore or .gitattributes
> at the toplevel would match everything under the sun.
In the case of `.gitignore`, `/foo/.` and `/foo/` would have the same
effect and they look sane to me.
> Would it be sensible to assume that users would not be surprised if
> ". text=auto" meant that the attribute applies to every file in the
> worktree?
I would be surprised as I expect `.` to be a "glob dot". But maybe it is
just me and my prejudices :)
Bye,
--
Gioele Barabucci <gioele@svario.it>
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Jeff King @ 2011-10-05 18:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <20111005175536.GB22962@sigill.intra.peff.net>
On Wed, Oct 05, 2011 at 01:55:36PM -0400, Jeff King wrote:
> On Tue, Oct 04, 2011 at 08:49:55PM +0200, Michael J Gruber wrote:
>
> > We seem to mean something different:
> >
> > git config --get remote.bitbucket.pushurl
> > https://grubix@bitbucket.org/grubix/git.git
> > SSH_ASKPASS= git push -n bitbucket
> > Username for 'bitbucket.org':
> >
> > I mean that git should not need to ask for the username here.
>
> No, we are in agreement about the intended behavior. I think you are
> seeing a bug. What version of git produced it?
>
> With my http-auth series, I get:
>
> $ git push https://github.com/peff/git.git
> Username for 'github.com':
>
> $ git push https://peff@github.com/peff/git.git
> Password for 'github.com':
>
> Using v1.7.7 produces similar results.
Hrm. I do get this, with the same version of git:
$ git config remote.foo.url https://github.com/peff/git.git
$ git push foo
Username for 'github.com':
$ git config remote.foo.url https://peff@github.com/peff/git.git
$ git push foo
Password for 'github.com':
So far so good. Now how about this:
$ git config remote.foo.url https://github.com/peff/git.git
$ git config remote.foo.pushurl https://peff@github.com/peff/git.git
$ git push foo
Username for 'github.com':
So I think the problem is with pushurl, not with the auth code. Oddly,
though, running GIT_TRACE reveals:
$ GIT_TRACE=1 git push foo
trace: built-in: git 'push' 'foo'
trace: run_command: 'git-remote-https' 'foo' 'https://peff@github.com/peff/git.git'
which is the right URL. So it's almost as if we are throwing away the
passed URL in favor of the configuration, and then looking up the
configuration wrong. I'm about to go get on a plane, so I don't have
more time to look at it now, but I suspect it's something simple and
stupid.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Junio C Hamano @ 2011-10-05 18:19 UTC (permalink / raw)
To: Jay Soffian; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_Dz-GXvRbYUXSoyfyHfOO-_BszcOza9x=ysHhmL5YBW-Jw@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Git has survived w/o needing to lock branches till now.
Careful. Git has survived without your patch series till now, as people
learned to be careful when they use separate workdirs and avoid certain
things, to the point that they are not necessarily aware that they are
avoiding them (one good practice is to keep the HEADs of non-primary
workdirs detached).
Does that mean what your patch aims to do is unnecessary? I think not.
> What are these
> use cases we cannot already think of today?
What is important is that we should have learned by now that the "gotchas"
live where we do not immediately see. "Can you tell me what you are missing?"
is a senseless thing to ask.
>> I think "switch_branches()" that updates HEAD to point at a local branch
>> is one good place to lock the branch, but I do not know if it is a good
>> idea to hook the check into the codepaths for deletion of the branch using
>> "branch -[dD]" and check-out of the branch using "checkout $branch". I
>> wonder if it makes sense to add the "checking" hook into much lower level
>> in the callchain, perhaps delete_ref(), rename_ref() and update_ref() to
>> catch attempts to update "your" current branch by other people.
>
> I don't think so. There are lots of ways to shoot yourself in the foot
> at the plumbing level. Besides, this is not about all refs, just local
> branches.
>
> Aside, there's nothing wrong with renaming a checked out branch.
There are pros and cons between hooking at lower level vs higher
level. The advantage of hooking at higher level is you do not risk
breaking low-level operations, but that directly results in allowing the
same low level operations that are unaware of the new requirement higher
level added break it. It also allows other high level operations you
forgot to teach the new requirement break it.
For example, you checkout branch frotz in a workdir, and then in the
primary repository that has nitfol branch checked out, you rename the
frotz branch to xyzzy. The HEAD of workdir still says refs/heads/frotz
that no longer exist. Of course you can break the same way by doing a
"update-ref -d refs/heads/frotz" from the primary repository.
Because you forgot that the high level operation "branch renaming" needs
to be aware of that "this branch is checked out elsewhere" information,
you allowed it to break the workdir. If you hooked into lower level
machinery that is shared, you wouldn't have caused this breakage.
Similarly, if delete_ref() were taught about the new requirement, you
would have covered both "branch -d" and "update-ref -d".
I do not necessarily think that it is a good approach to forbid the same
branch to be checked out in two different places, by the way. One reason
people would want to keep multiple workdirs is so that while they are
still working on a branch and are not yet at a good "stop point" to even
make a temporary commit to get interrupted, they find it sometimes
necessary to be able to build the tip of that same branch and even make a
small in-working-tree fixes (which later will be carried back to the
primary branch). The problem arises only when one of the repositories try
to update or delete the branch while it is checked out in another working
tree.
Can this series be extended/reworked so that:
- Each branch has multi-value configuration record to note the workdirs
that it is checked out;
- Error out (or warn if forced) upon any attempt to update the tip of a
branch that is checked out in more than one place; and
- Similarly for renaming or deleting a branch that is checked out in more
than one place.
^ permalink raw reply
* Re: Git Bug report
From: Federico Lucifredi @ 2011-10-05 18:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4E8BF519.8090509@viscovery.net>
On Wed, 2011-10-05 at 08:11 +0200, Johannes Sixt wrote:
> >> federico@skyplex:/etc$ git log
> >> fatal: Not a git repository (or any of the parent directories): .git
> >
> > with correct access permissions, everything works as expected.
>
> And the correct error message is...?
".git: permission denied" -- no need to be fatal (there could
be ../.git, etc - fatal comes only if those don't exist).
It could fail silently if one of the parents exists, but in the fatal
scenario, I should be told that it was by permission denied. Currently,
I am told there is no git repo where I know there to be one, which means
"what happened to my repo" is the next question in the user's head.
"it's there but it is broke" is the subtext one gets from this error. it
should be "it is there, I cannot get to it".
> >> drwx------ 8 root root 4096 2011-10-03 16:53 .git
>
> Assuming that you expected something like this:
>
> fatal: .git: permission denied
>
> it is hard to argue that a directory that happens to be named .git, but
> was sealed by its owner should be assumed to be a git repository, albeit
> one that we do not have access to. "Not a git repository" is an equally
> justifyable error message, IMHO.
An error message should help resolve the error in question, not grade
the user's smarts. Here I as a user had an expectation that there was a
git repository for /etc ("I set up one!") and figured the permission
issue with my own wits (well, I did not need to because it was /etc, but
in the general perm-denied case I would have had to), by looking at the
dir because the message gave me no useful information on the cause of
the problem.
Thanks -Federico
--
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - federico at canonical.com - GnuPG 0x4A73884C
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Junio C Hamano @ 2011-10-05 18:35 UTC (permalink / raw)
To: Gioele Barabucci; +Cc: Michael Haggerty, git
In-Reply-To: <4E8C9A35.5030504@svario.it>
Gioele Barabucci <gioele@svario.it> writes:
> On 05/10/2011 19:38, Junio C Hamano wrote:
>>> In fact the support for gitattributes using patterns involving "." was
>>> pretty spotty in v1.7.6 too. For example,
>>
>> The attribute patterns (or exclude patterns for that matter) were never
>> designed to name "the current directory". The way to name "everything *in*
>> this directory" has always been to say "*" (the "* text=auto" example in
>> the documentation says it shows how to set the attribute "for all
>> files"). Admittedly the pattern may miss ".*" files.
>
> What if I do not want to say things about the "content" of the
> directory but about the directory itself? This is exactly my case.
Oh, that is totally different. We do not store directories, and they do
not have attributes, period.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vzkhf713u.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 2:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Careful. Git has survived without your patch series till now, as people
> learned to be careful when they use separate workdirs and avoid certain
> things, to the point that they are not necessarily aware that they are
> avoiding them (one good practice is to keep the HEADs of non-primary
> workdirs detached).
I think it's more likely the case that most people have avoided
new-workdir entirely.
Also, while I might recommend new-workdir to my coworkers with the
advice "don't checkout the same branch in multiple workdirs", never in
a million years would I say "use new-workdir, but make sure to only
use a detached HEAD in the workdirs." The latter would make their
actual HEADs explode. :-)
> For example, you checkout branch frotz in a workdir, and then in the
> primary repository that has nitfol branch checked out, you rename the
> frotz branch to xyzzy. The HEAD of workdir still says refs/heads/frotz
> that no longer exist. Of course you can break the same way by doing a
> "update-ref -d refs/heads/frotz" from the primary repository.
>
> Because you forgot that the high level operation "branch renaming" needs
> to be aware of that "this branch is checked out elsewhere" information,
> you allowed it to break the workdir. If you hooked into lower level
> machinery that is shared, you wouldn't have caused this breakage.
> Similarly, if delete_ref() were taught about the new requirement, you
> would have covered both "branch -d" and "update-ref -d".
I did not forget, I just hadn't gotten there yet while this was still
an RFC/PATCH.
Another issue to resolve is what happens when the workdir or repo are
moved in the filesystem. And making prune aware of HEAD reflogs in the
alternate workdirs.
> I do not necessarily think that it is a good approach to forbid the same
> branch to be checked out in two different places, by the way. One reason
> people would want to keep multiple workdirs is so that while they are
> still working on a branch and are not yet at a good "stop point" to even
> make a temporary commit to get interrupted, they find it sometimes
> necessary to be able to build the tip of that same branch and even make a
> small in-working-tree fixes (which later will be carried back to the
> primary branch). The problem arises only when one of the repositories try
> to update or delete the branch while it is checked out in another working
> tree.
That is not at all my experience of how workdirs are used.
> Can this series be extended/reworked so that:
>
> - Each branch has multi-value configuration record to note the workdirs
> that it is checked out;
This is a good idea in any case for when "checkout --force" is used
(see below), so that we can find all the workdirs for other operations
that may need to.
> - Error out (or warn if forced) upon any attempt to update the tip of a
> branch that is checked out in more than one place; and
I think that's a worse user experience. "Sorry, can't commit your
changes because you've checked out this branch elsewhere." Now the
user's choices are:
1. commit --force (and thus confusing the other workdirs)
2. checkout -b new_branch && commit
Both of which I think are worse than preventing the checkout in the first place.
> - Similarly for renaming or deleting a branch that is checked out in more
> than one place.
Yep.
j.
^ permalink raw reply
* Re: [PATCH 1/1] get_sha1_hex(): do not read past a NUL character
From: Thomas Rast @ 2011-10-05 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7vaa9vulsw.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
> > Previously, get_sha1_hex() would read one character past the end of a
> > null-terminated string whose strlen was an even number less than 40.
> > Although the function correctly returned -1 in these cases, the extra
> > memory access might have been to uninitialized (or even, conceivably,
> > unallocated) memory.
> >
> > Add a check to avoid reading past the end of a string.
>
> Makes sense; thanks.
Has this fixed patch ever made it to pu? I'm still seeing the same
breakage in the automated valgrind runs.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vzkhf713u.fsf@alter.siamese.dyndns.org>
Aside, previous discussion -
http://thread.gmane.org/gmane.comp.version-control.git/150559
Sadly, it seems to have petered out, it looks to me like a case of
perfect being the enemy of the good. I'm really just trying to make it
good enough that we can move new-workdir out of contrib. It's a
valuable tool, we just need to remove some of its sharper edges.
j.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Andreas Krey @ 2011-10-05 20:00 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_Dzg2D+vmFRfLX01S2k98YZQBE0FFv76VAyPnXdetyWADQ@mail.gmail.com>
On Wed, 05 Oct 2011 15:11:30 +0000, Jay Soffian wrote:
...
> > - Error out (or warn if forced) upon any attempt to update the tip of a
> > branch that is checked out in more than one place; and
>
> I think that's a worse user experience. "Sorry, can't commit your
> changes because you've checked out this branch elsewhere."
This is actually pretty much the same as "you can't push into the
currently checked-out branch".
I do come from CVS where multiple checkouts of the same branch are obviously
common, but the semantics are different. git would need to allow to be in
a detached state but still have a notion of a 'current' branch to mimic that;
this tentative 'current' branch being what we need to merge or rebase onto later.
Just thinking.
It may actually be logical to put the other workdirs into detached state when
the branch they are on is committed into; however, this is seriously confusing.
> Now the
> user's choices are:
>
> 1. commit --force (and thus confusing the other workdirs)
> 2. checkout -b new_branch && commit
>
> Both of which I think are worse than preventing the checkout in the first place.
Hmm. You mean forcing the user to make a new branch *earlier* than at
commit time is better?
Andreas
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Gioele Barabucci @ 2011-10-05 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7vvcs370d1.fsf@alter.siamese.dyndns.org>
On 05/10/2011 20:35, Junio C Hamano wrote:
>> What if I do not want to say things about the "content" of the
>> directory but about the directory itself? This is exactly my case.
>
> Oh, that is totally different. We do not store directories, and they do
> not have attributes, period.
While that is true (yet many beg git to natively support empty dirs…),
`.gitignore` does deal with directories. As you quoted,
> If the pattern ends with a slash, it is removed for the purpose
> of the following description, but it would only find a match with
> a directory. In other words, foo/ will match a directory foo and
> paths underneath it
Isn't applying the same logic to `.gitattributes` be the most
straightforward solution? Also code-wise, I suppose.
Bye,
--
Gioele Barabucci <gioele@svario.it>
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Junio C Hamano @ 2011-10-05 20:25 UTC (permalink / raw)
To: Gioele Barabucci; +Cc: Michael Haggerty, git
In-Reply-To: <4E8CBB4C.4000408@svario.it>
Gioele Barabucci <gioele@svario.it> writes:
> ... As you quoted,
>
>> If the pattern ends with a slash, it is removed for the purpose
>> of the following description, but it would only find a match with
>> a directory. In other words, foo/ will match a directory foo and
>> paths underneath it
But the "will match a directory foo and" part in that description, while
makes it easier to read, is technically unnecessary and even misleading.
The ignore patterns ultimately decides which paths are not to be added to
the index. Colloquially we could say "foo directory is ignored", but such
a statement is just a short-hand for "everything in foo is ignored";
technically "foo directory is ignored" is not necessary because we never
add the directory itself to the index.
^ permalink raw reply
* Re: [PATCH 1/1] get_sha1_hex(): do not read past a NUL character
From: Junio C Hamano @ 2011-10-05 20:37 UTC (permalink / raw)
To: Thomas Rast; +Cc: Michael Haggerty, git
In-Reply-To: <201110052111.52701.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>> > Previously, get_sha1_hex() would read one character past the end of a
>> > null-terminated string whose strlen was an even number less than 40.
>> > Although the function correctly returned -1 in these cases, the extra
>> > memory access might have been to uninitialized (or even, conceivably,
>> > unallocated) memory.
>> >
>> > Add a check to avoid reading past the end of a string.
>>
>> Makes sense; thanks.
>
> Has this fixed patch ever made it to pu? I'm still seeing the same
> breakage in the automated valgrind runs.
I do not think so.
I was under the impression that Michael wanted to include this in the
early part of a re-roll of check-ref-format series.
I'll do the rebase myself. Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 20:50 UTC (permalink / raw)
To: Andreas Krey; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20111005200043.GA32732@inner.h.iocl.org>
On Wed, Oct 5, 2011 at 4:00 PM, Andreas Krey <a.krey@gmx.de> wrote:
> Hmm. You mean forcing the user to make a new branch *earlier* than at
> commit time is better?
In my mind, we're trying to make new-workdir usable for non-advanced
users. I think it's conceptually simplest to allow a branch to be
checked out only once.
FWIW, I use a modified copy of new-workdir w/this usage:
git new-workdir <repo> <workdir> <ref> [<start>]
Which allows me to create a new branch and workdir checked out to the
new branch in one shot. It refuses to create the <workdir> if <ref>
resolves to a checked-out branch. (If I want to start detached I can
do so with <ref>^0, but I rarely if ever do that.)
j.
^ permalink raw reply
* [ANNOUNCE] libgit2 v0.15.0
From: Vicent Marti @ 2011-10-05 21:00 UTC (permalink / raw)
To: libgit2, git, git-dev
Hello everyone,
another minor libgit2 release is here. This time with proper
networking support, even on Windows/MSVC.
The release has been tagged at:
https://github.com/libgit2/libgit2/tree/v0.15.0
A dist package can be found at:
https://github.com/downloads/libgit2/libgit2/libgit2-0.15.0.tar.gz
Updated documentation can be found at:
http://libgit2.github.com/libgit2/
The full change log follows after the message.
Cheers,
Vicent
================
libgit2 v0.15.0 "Das Wunderbar Release"
I am aware the codename is not gramatically correct in any language.
Check the COPYING file for the detailed terms on libgit2's license. Check
the AUTHORS file for the full list of guilty parties.
As we slowly stabilize the API, we've dropped 1 function from the library,
and changed the signature of only 5 of them.
In this release of libgit2:
* `git_blob_rawsize`: Now returns `size_t` instead of int, allowing
files >4GB in 64 bit systems.
- `git_commit_message_short`: Please use `git_commit_message`
to get the full message and decide which is the "short view" according
to your needs (first line, first 80 chars...)
+ `git_commit_message_encoding`: Returns the encoding field of a commit
message, if it exists.
* `git_commit_create`, `git_commit_create_v`: New argument `encoding`, which
adds a encoding field to the generated commit object.
+ `git_config_find_system`: Returns the path to the system's global config
file (according to the Core Git standards).
* `git_config_get_XX`, `git_config_set_XX`: the `long` and `int` types have
been replaced by `int64` and `int32` respectively, to make their meaning more
obvious.
+ `git_indexer`: An interface to index Git Packfiles has been added in the
`git2/indexer.h` header.
* `git_reflog_entry_XX`: Reflog entries are now returned as `git_oid *` objects
instead of hexadecimal OIDs.
+ `git_remote`: More fetch functionality has been added to the `git2/remote.h`
functionality. Local, Smart HTTP and Git protocols are now supported.
+ `git_repository_head`: Returns the HEAD of the repository.
+ `git_repository_config_autoload`: Opens the configuration file of a
repository,
including the user's and the system's global config files, if they
can be found.
* `git_signature_now`: Now returns an error code; the signature is stored by
reference.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Junio C Hamano @ 2011-10-05 21:29 UTC (permalink / raw)
To: Jay Soffian; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_Dzg2D+vmFRfLX01S2k98YZQBE0FFv76VAyPnXdetyWADQ@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Oct 5, 2011 at 2:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Also, while I might recommend new-workdir to my coworkers with the
> advice "don't checkout the same branch in multiple workdirs", never in
> a million years would I say "use new-workdir, but make sure to only
> use a detached HEAD in the workdirs." The latter would make their
> actual HEADs explode. :-)
>
>> ...
>> Because you forgot that the high level operation "branch renaming" needs
>> to be aware of that "this branch is checked out elsewhere" information,
>> you allowed it to break the workdir. If you hooked into lower level
>> machinery that is shared, you wouldn't have caused this breakage.
>> Similarly, if delete_ref() were taught about the new requirement, you
>> would have covered both "branch -d" and "update-ref -d".
>
> I did not forget, I just hadn't gotten there yet while this was still
> an RFC/PATCH.
You conveniently also forgot that you also said:
> Aside, there's nothing wrong with renaming a checked out branch.
With that lack of understanding, it wasn't "hadn't gotten there", but was
actually "didn't even know it was needed".
But that is OK. We have discussions to find out what we missed by learning
from others' insights.
> Another issue to resolve is what happens when the workdir or repo are
> moved in the filesystem. And making prune aware of HEAD reflogs in the
> alternate workdirs.
>
>> I do not necessarily think that it is a good approach to forbid the same
>> branch to be checked out in two different places, by the way. One reason
>> people would want to keep multiple workdirs is so that while they are
>> still working on a branch and are not yet at a good "stop point" to even
>> make a temporary commit to get interrupted, they find it sometimes
>> necessary to be able to build the tip of that same branch and even make a
>> small in-working-tree fixes (which later will be carried back to the
>> primary branch). The problem arises only when one of the repositories try
>> to update or delete the branch while it is checked out in another working
>> tree.
>
> That is not at all my experience of how workdirs are used.
I am afraid to say, with that statement, that your knowledge about the way
the tool can be used is not wide enough to judge if one policy restriction
(e.g. "never check out the same branch in multiple places") is general
enough to add to the tool. I do not claim mine is good enough, but I at
least know better than proposing a rule that may be too restictive to
negatively affect other people's workflows.
I always maintain four workdirs that I can use to build the tip of four
integration branches while I work on other things in the primary branch,
plus another that has a detached HEAD so that I can "reset --hard" around
without having to worry about what I do there would negatively affect what
I do elsewhere or vice versa. Of course, updating 'master' in my primary
repository will require the "build master" workdir to be "reset --hard"
before it is used, and that is part of my workflow already. I consider it
is one of "people learned to work around the restriction of the tool so
well already that they may not realize it" we discussed earlier.
Also, if your goal is to give a different semantics, like:
> In my mind, we're trying to make new-workdir usable for non-advanced
> users. I think it's conceptually simplest to allow a branch to be
> checked out only once.
you would really need to make sure that your changes would not harm other
users of the same tool that you are not targetting for, and also the
changes to the core part of the system that needs your specialized policy
makes sense in the wider context. The former you can claim "the policy
does not kick in when configuration is not set", but that is weak if the
policy is too ad-hoc and not well thought out. I actually care about the
latter more, as it is not worth having to spend maintenance effort to
carry changes that only stop some but not other kind of mistakes in the
core part to be more widely applicable.
^ permalink raw reply
* 66 patches and counting
From: Michael Haggerty @ 2011-10-05 21:29 UTC (permalink / raw)
To: git
My renovation of refs.c [1] is currently at 66 patches and counting.
What can I say?: (1) I like to make changes in the smallest irreducible
steps and (2) there is a lot that needed to be done in refs.c.
When I'm done, is it OK to dump a patch series like that on the git
mailing list? Is it pointless because nobody will review them anyway?
Is a big pile of changes like this welcome in any form? Would it be
better to convey the changes via git itself (e.g., github) rather than
via emails?
Michael
[1] hierarchical-refs at git://github.com/mhagger/git.git
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jonathan Nieder @ 2011-10-05 21:30 UTC (permalink / raw)
To: Jay Soffian; +Cc: Andreas Krey, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_DynQ8U6T9YMsWstKF_Cf6CSCr8b8E4T=p5uyGPh28G=kA@mail.gmail.com>
Jay Soffian wrote:
> In my mind, we're trying to make new-workdir usable for non-advanced
> users.
I'd be happy already with making it comfortable for the advanced
users. :)
I think your patch goes in a right direction (using the shared
.git/config file as a way to negotiate ownership of branches).
Junio’s comments about it seeming sensible to
- make this apply to other operations that clobber a branch
- make the “[branch "master"] checkedout” configuration multi-valued
if there is to be support for "git checkout -f" overriding this at
all
ring true to me. Making the value of this variable the path to the
.git dir or worktree (rather than an opaque string) seems like a very
good thing: it means that a future git could check if the directory
still exists and break the lock if someone has used “rm -fr”.
As for moving “git new-workdir” out of contrib, I believe another
prerequisite is sharing the HEAD reflog.
Just my two cents,
Jonathan
^ permalink raw reply
* Re: 66 patches and counting
From: Junio C Hamano @ 2011-10-05 21:36 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4E8CCC55.9070408@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> When I'm done, is it OK to dump a patch series like that on the git
> mailing list?
Bits and pieces that are of digestable sizes.
I would wait sending anything large-ish (like more than 10 patches) before
'next' is rewound, which is the sign the cycle is in full swing.
> Is it pointless because nobody will review them anyway?
Bits and pieces that are of digestable sizes. Especially given:
> I like to make changes in the smallest irreducible steps
each step in your series should make sense by itself already (otherwise
you would have rebase-i'ed them to collapse too-small pieces into one that
makes sense standalone on top of the earlier steps).
> Is a big pile of changes like this welcome in any form?
Bits and pieces that are of digestable sizes.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vy5wz5dql.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 5:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I am afraid to say, with that statement, that your knowledge about the way
> the tool can be used is not wide enough to judge if one policy restriction
> (e.g. "never check out the same branch in multiple places") is general
> enough to add to the tool. I do not claim mine is good enough, but I at
> least know better than proposing a rule that may be too restictive to
> negatively affect other people's workflows.
>
> I always maintain four workdirs that I can use to build the tip of four
> integration branches while I work on other things in the primary branch,
> plus another that has a detached HEAD so that I can "reset --hard" around
> without having to worry about what I do there would negatively affect what
> I do elsewhere or vice versa. Of course, updating 'master' in my primary
> repository will require the "build master" workdir to be "reset --hard"
> before it is used, and that is part of my workflow already. I consider it
> is one of "people learned to work around the restriction of the tool so
> well already that they may not realize it" we discussed earlier.
Is it a regression to your workflow that you have to now use "checkout
-f" instead of "checkout" to checkout the same branch in more than one
location?
> Also, if your goal is to give a different semantics, like:
>
>> In my mind, we're trying to make new-workdir usable for non-advanced
>> users. I think it's conceptually simplest to allow a branch to be
>> checked out only once.
>
> you would really need to make sure that your changes would not harm other
> users of the same tool that you are not targetting for, and also the
> changes to the core part of the system that needs your specialized policy
> makes sense in the wider context. The former you can claim "the policy
> does not kick in when configuration is not set", but that is weak if the
> policy is too ad-hoc and not well thought out. I actually care about the
> latter more, as it is not worth having to spend maintenance effort to
> carry changes that only stop some but not other kind of mistakes in the
> core part to be more widely applicable.
Perhaps:
core.multipleCheckouts = {true,false}
- false prevents multiple checkouts without -f
advice.multipleCheckouts = {true,false}
- false disables multiple-checkout notice
And when there are multiple checkouts, warn on committing about other
workdirs that now need reset --hard.
j.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 21:52 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Andreas Krey, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20111005213002.GA12667@elie>
On Wed, Oct 5, 2011 at 5:30 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> As for moving “git new-workdir” out of contrib, I believe another
> prerequisite is sharing the HEAD reflog.
I don't understand this. Is it about not gc'ing commits that other
workdirs are detached on, or something more?
I like that each of my workdirs have their own HEAD reflog.
j.
^ permalink raw reply
* Re: 66 patches and counting
From: Jonathan Nieder @ 2011-10-05 21:55 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Elijah Newren
In-Reply-To: <4E8CCC55.9070408@alum.mit.edu>
(+cc: Elijah, who has more experience in this subject than I do)
Hi,
Michael Haggerty wrote:
> My renovation of refs.c [1] is currently at 66 patches and counting.
> What can I say?: (1) I like to make changes in the smallest irreducible
> steps and (2) there is a lot that needed to be done in refs.c.
>
> When I'm done
We've seen series with fifty-something patches on this list before.
My (generic) advice:
1. Send in installments, early and often. It would not be fun if the
first ten patches have a fatal flaw that means the later ones have
to be reworked.
2. Make sure the cover letter makes people want to read the later
patches. Make sure each patch has a commit message that motivates
it alone or explains how it fits into the larger picture.
3. When a patch is not intended to cause any functional change, say
so, so reviewers can check that.
4. Include test scripts declaring what effect (or lack thereof) each
patch is supposed to have.
5. "Smallest irreducible step" is not necessarily the appropriate
granularity when publishing. "Largest piece that a person would
want to review, apply, or revert independently" is.
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Junio C Hamano @ 2011-10-05 21:55 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, nicolas.dichtel
In-Reply-To: <CAG+J_Dyn3kk7SfNZzxjoD-hK9jBQr2igmOqJojeYNHLubtSY=w@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Oct 5, 2011 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Pinging Jay who may have know a thing or two from the history leading to
>> 37f7a85 (Teach commit about CHERRY_PICK_HEAD, 2011-02-19).
>
> Yep, I replied to Nicolas' other message.
>
> j.
This is probably different fro Nicolas's use case, but you can easily
trigger:
$ edit foo.c
$ EDITOR=: git commit --amend ;# forget to add foo.c
$ git cherry-pick other
error: Your local changes to the following files would be overwritten by
merge:
foo.c
Please, commit your changes or stash them before you can merge.
Aborting
$ EDITOR=: git commit --amend foo.c
fatal: You are in the middle of a cherry-pick -- cannot amend.
I think the sequencer state needs to be removed when the command aborts.
This needs to be fixed before 1.7.7.1.
^ permalink raw reply
* Re: Git Bug report
From: Nguyen Thai Ngoc Duy @ 2011-10-05 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Gustafsson, Federico Lucifredi, git
In-Reply-To: <7vlisz8jur.fsf@alter.siamese.dyndns.org>
On Thu, Oct 6, 2011 at 3:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> So if:
>> .git/ is a directory with not enough permissions.
>> ../.git/ is a directory with enough permissions.
>>
>> git would today use ../.git. You suggest that git instead would die
>> because a .git/ exists? (I'm not saying this is wrong or right).
>
> For that matter, if you have .git/ that is a directory but is not a
> repository, and ../.git/ that is, the same situation would arise. I do not
> think we should die because .git/ is not a git repository. I do not know
> if we should even warn about it.
Probably not. On the other hand we should show user how we ignored
.git if we find no good repository in the end. So maybe it's a good
idea to queue up warnings and only print before git calls die("Not a
repository").
--
Duy
^ 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