Re: Proposal: sharing .git/config
On Mon, Mar 18, 2013 at 02:30:23PM +0530, Ramkumar Ramachandra wrote: Jeff King wrote: I don't think you can avoid the 3-step problem and retain the safety in the general case. Forgetting implementation details for a minute, you have either a 1-step system: 1. Fetch and start using config from the remote. which is subject to fetching and executing malicious config, or: 1. Fetch config from remote. 2. Inspect it. 3. Integrate it into the current config. I don't understand your emphasis on step 2. Isn't the configuration written by me? Why would it be malicious? Maybe I am misunderstanding the use case, but when people talk about share config, they are often talking about pushing project-wide config out to developers. So the config is not necessarily written by you, but by somebody who had write access to the upstream repository. The obvious counterpoint is that people usually run make right after fetching, so they are trusting what they fetched already. And the counter-counterpoint is that yes, that's true, but at least with the make case they can use git to inspect the differences before running them. You may be able to tell that this is not the first time this discussion has happened. :) Personally, I do not think it is the end of the world for people to opt into the automatically fetch and respect config method for certain repositories (and that's why I wrote include.ref support a while ago). It's a security tradeoff that the user may want to make. But I also respect the argument that we should not be endorsing risky behavior by advertising such a feature (especially when the risk is quite subtle, as many users may not realize that git config can execute arbitrary code). I've just started thinking about how to design something that will allow us to share configuration elegantly [1]. Essentially, the metadata repository will consist of *.layout files, one for each repository to clone, containing the .git/config to write after cloning that repository. So, a git.layout might look like: [layout] directory = git [remote origin] url = git://github.com/git/git [remote ram] url = g...@github.com:artagnon/git [remote junio] url = git://github.com/gitster/git As you can see the [layout] is a special section which will tell our fetcher where to place the repository. Everything else is meant to be inserted into the repository's .git/config. However, I can foresee a problem in scaling: when I ask a specific directory like a/b/c to be populated (equivalent of repo sync `a/b/c`), it'll have to parse the layout.directory variable of all the .layout files, and this can be slow. So, maybe we should have a special _manifest.layout listing all the paths? Further, I see this as a way to work with projects that would otherwise require nested submodules like the Android project. What do you think? Yeah, reading your layout description, this is less about git config in particular, and more about managing hierarchies of repos. Which I think is a fine thing to do, and is a sensible place to put config management (since you are probably executing arbitrary code as part of the layout tool anyway). But I don't have a real opinion on the design of such a tool. I have used repo only once or twice to deal with Android. For my own menagerie of small repos, I have a hacky custom tool that is mostly about deciding when there are items to be committed, pushed, or fetched in each repo; I never found the need to handle git config at all. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
On Tue, Mar 12, 2013 at 01:01:08AM +0530, Ramkumar Ramachandra wrote: But it was pointed out that you could also just do: $ git config include.ref upstream-config $ git show origin/config ;# make sure it looks reasonable $ git show origin/config .git/upstream-config and so forth. There are some ways that a pure ref can be more convenient (e.g., if you are carrying local changes on top of the upstream config and want to merge), but ultimately, you can replicate any include.ref workflow with include.path by adding a deploy step where you copy the file into $GIT_DIR. This seems to be unnecessarily complex and inelegant. Maybe this functionality is best managed as a separate git repository: `repo` from depot_tools uses a manifest repository containing all the project metadata. Maybe we can extend it/ write an more general version? I don't think you can avoid the 3-step problem and retain the safety in the general case. Forgetting implementation details for a minute, you have either a 1-step system: 1. Fetch and start using config from the remote. which is subject to fetching and executing malicious config, or: 1. Fetch config from remote. 2. Inspect it. 3. Integrate it into the current config. We can automate the sequence to remove as much friction as possible, but fundamentally step 2 requires some effort from the user. Moving the config to a separate repo does not get rid of those steps. The user either does not look at the config before using it, in which case we are no better than the 1-step scenario, or they do, in which case they are replicating the 3-step scenario. The other alternative is to automate step 2. The simplest way would be to have a whitelist of ok to share config, that would not include things like diff.external that can run arbitrary code. I don't know whether that would make the system too limited for what people want to do. Do we have a concrete example of what config people would like to share in this manner? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
Jeff King wrote: On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) on the repository. The only problem is that I have no clue how to implement this: I'm currently thinking a special remote ref? If you check out the config file, then include.path should work. You could add include.ref to point to a ref, but you need to deal with the attached security implications. This has been proposed before (and turned down, I think). Here's the patch: http://article.gmane.org/gmane.comp.version-control.git/189144 The basic argument against it is that you would _not_ want to do: $ git config include.ref origin/config because it's unsafe (you immediately start using config fetched from the remote, before you even get a chance to inspect it). So the recommended way to use it is: $ git config include.ref config $ git show origin/config ;# make sure it looks reasonable $ git update-ref refs/config origin/config [time passes...] $ git fetch $ git diff config origin/config ;# inspect changes $ git update-ref refs/config origin/config But it was pointed out that you could also just do: $ git config include.ref upstream-config $ git show origin/config ;# make sure it looks reasonable $ git show origin/config .git/upstream-config and so forth. There are some ways that a pure ref can be more convenient (e.g., if you are carrying local changes on top of the upstream config and want to merge), but ultimately, you can replicate any include.ref workflow with include.path by adding a deploy step where you copy the file into $GIT_DIR. This seems to be unnecessarily complex and inelegant. Maybe this functionality is best managed as a separate git repository: `repo` from depot_tools uses a manifest repository containing all the project metadata. Maybe we can extend it/ write an more general version? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
Ramkumar Ramachandra artag...@gmail.com writes:
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone.
Note that you need to carefully pick only certain bits of the config, as
otherwise there are big security headaches.
There are also other things in .git/config that would be nice to
share, like whether to do a --word-diff (why isn't it a configuration
variable yet?)
Because that would break pretty much every script that uses git-diff?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
Thomas Rast wrote: Ramkumar Ramachandra artag...@gmail.com writes: I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. Note that you need to carefully pick only certain bits of the config, as otherwise there are big security headaches. Right. So, we can just start with remotes for the moment? Ideally, there should be a way to specify which configuration options to publish. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) Because that would break pretty much every script that uses git-diff? diff.c already makes a differentiation between git_diff_ui_config() and git_diff_basic_config(); there are configuration options that should only be applied when the command is called interactively. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) on the repository. The only problem is that I have no clue how to implement this: I'm currently thinking a special remote ref? If you check out the config file, then include.path should work. You could add include.ref to point to a ref, but you need to deal with the attached security implications. This has been proposed before (and turned down, I think). -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
Ramkumar Ramachandra artag...@gmail.com writes:
Thomas Rast wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
There are also other things in .git/config that would be nice to
share, like whether to do a --word-diff (why isn't it a configuration
variable yet?)
Because that would break pretty much every script that uses git-diff?
diff.c already makes a differentiation between git_diff_ui_config()
and git_diff_basic_config(); there are configuration options that
should only be applied when the command is called interactively.
It still breaks every other use of diff unless you make the diff output
depend on whether the user runs directly at the terminal (possibly using
git's own paging).
For example, if you just say something like 'git diff file' for
inclusion in an email, you expect that to be a git-apply compatible
diff.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
On Tue, Feb 19, 2013 at 9:25 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) on the repository. The only problem is that I have no clue how to implement this: I'm currently thinking a special remote ref? I handle these kinds of configuration tasks out of band using mr, and it works pretty well: https://github.com/aspiers/mr-config/#readme https://github.com/aspiers/mr-config/blob/master/sh.d/git-remotes Food for thought ... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) on the repository. The only problem is that I have no clue how to implement this: I'm currently thinking a special remote ref? If you check out the config file, then include.path should work. You could add include.ref to point to a ref, but you need to deal with the attached security implications. This has been proposed before (and turned down, I think). Here's the patch: http://article.gmane.org/gmane.comp.version-control.git/189144 The basic argument against it is that you would _not_ want to do: $ git config include.ref origin/config because it's unsafe (you immediately start using config fetched from the remote, before you even get a chance to inspect it). So the recommended way to use it is: $ git config include.ref config $ git show origin/config ;# make sure it looks reasonable $ git update-ref refs/config origin/config [time passes...] $ git fetch $ git diff config origin/config ;# inspect changes $ git update-ref refs/config origin/config But it was pointed out that you could also just do: $ git config include.ref upstream-config $ git show origin/config ;# make sure it looks reasonable $ git show origin/config .git/upstream-config and so forth. There are some ways that a pure ref can be more convenient (e.g., if you are carrying local changes on top of the upstream config and want to merge), but ultimately, you can replicate any include.ref workflow with include.path by adding a deploy step where you copy the file into $GIT_DIR. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Jonathan Nieder jrnie...@gmail.com writes: Wait, why did the remote rewind? Oh, I am very well aware of that glitch. git push has this hack to pretend as if the pusher immediately turned around and fetched from the remote. It shouldn't have been made to do so unconditionally; instead it should have been designed to give the pushee a way to optionally tell you I acccept this push, but you may not see it to be updated to that exact value you pushed when you fetched from me right now. The hack is not my design; it was not even something I accepted without complaints, so I can badmouth about it all I want without hesitation ;-) More importantly, we could fix it if we wanted to. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:
To support a triangular arrangement well, there may need some
thinking on what $branch@{upstream} means. The original intent of
the upstream mode specified for push.default is push the result
back to what you based your work on, but in a triangular arrangement
that is no longer true.
I don't think that upstream or simple push settings really make
sense in such a triangular arrangement. And IMHO, that's OK. They
reflect a much simpler view of the world than git is capable of
supporting. So simple works OK as a default, and people can move to
matching (or current, or even a custom refspec) once they have are
ready to take advantage of a more advanced topology/workflow.
We have the problem now that new users do not necessarily understand the
matching strategy, or why it is useful, and get confused. When we move
to simple, we may be switching to a world where the early part of the
learning curve is more gentle for those users, but they eventually run
across the steeper part when they want to adjust their workflow (i.e.,
they will eventually learn about non-symmetric repo topologies because
those are part of many useful workflows).
But I think it's a good thing to push that part of the learning curve
out, because:
1. Some people may stay in the centralized view their whole lives and
never care.
2. It will make more sense to them, because they'll understand how it
fits into what they're trying to do, rather than viewing it as an
arcane and senseless default.
There may be some confusion as people hit that learning point. I won't
be surprised if we end up adding more advice.* messages in certain cases
to guide people to adjusting their push.default. But I'm just as happy
to wait until people start hitting the confusion point in practice, and
we can see more clearly when that advice should trigger, and what it
should say.
Unless you have ideas now, of course, in which case I'm happy to hear
them. :)
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16: Jonathan Nieder jrnie...@gmail.com writes: Wait, why did the remote rewind? Oh, I am very well aware of that glitch. git push has this hack to pretend as if the pusher immediately turned around and fetched from the remote. It shouldn't have been made to do so unconditionally; instead it should have been designed to give the pushee a way to optionally tell you I acccept this push, but you may not see it to be updated to that exact value you pushed when you fetched from me right now. The hack is not my design; it was not even something I accepted without complaints, so I can badmouth about it all I want without hesitation ;-) More importantly, we could fix it if we wanted to. And this seems to be more natural, too. It can keep the internals (the auxiliary ref on the server side) hidden from the user. As for the triangle remote, I really think we should clean up the situation regarding push, pushurlinsteadof and the various different and inconclusive output formats of git remote (with or without -v, with or without a remote name) first, before introducing yet another way to twist things around. git push downstream does not hurt any kittens (while git remote ouput does, somehwat). Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Michael J Gruber g...@drmicha.warpmail.net writes: As for the triangle remote, I really think we should clean up the situation regarding push, pushurlinsteadof and the various different and inconclusive output formats of git remote (with or without -v, with or without a remote name) first, before introducing yet another way to twist things around. git push downstream does not hurt any kittens (while git remote ouput does, somehwat). As people tend to fetch more often than they push if they are working on a real project where the others as a whole will be far more productive than any single individual, I agree that keeping git fetch (or git pull) lazy by having origin point at where they fetch from and be a bit more explicit in git push would actually make sense. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Michael J Gruber g...@drmicha.warpmail.net writes: Junio C Hamano venit, vidit, dixit 08.02.2013 09:16: Jonathan Nieder jrnie...@gmail.com writes: Wait, why did the remote rewind? Oh, I am very well aware of that glitch. git push has this hack to pretend as if the pusher immediately turned around and fetched from the remote. It shouldn't have been made to do so unconditionally; instead it should have been designed to give the pushee a way to optionally tell you I acccept this push, but you may not see it to be updated to that exact value you pushed when you fetched from me right now. The hack is not my design; it was not even something I accepted without complaints, so I can badmouth about it all I want without hesitation ;-) More importantly, we could fix it if we wanted to. And this seems to be more natural, too. It can keep the internals (the auxiliary ref on the server side) hidden from the user. Fixing that misfeature to always pretend it immediately turned around and fetched may have a different benefit, too. A straightforward and simple solution to Ram's original problem may be to define pushurl to point at his publishing repository after all, and teach git push not to pretend it immediately fetched with the same fix. [remote origin] url = ... where Ram fetches and pulls from ... pushurl = ... where Ram pushes to ... fetch = refs/heads/*:refs/remotes/* updateTrackOnPush = no Then git fetch (or git pull) will update the remote tracking branches Ram fetches from, and once his topic is finished, he can push to his publishing location, which won't touch the remote tracking branches used to keep track of the place he fetches from. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Junio C Hamano wrote: Jeff King p...@peff.net writes: We have the problem now that new users do not necessarily understand the matching strategy, or why it is useful, and get confused. When we move to simple, we may be switching to a world where the early part of the learning curve is more gentle for those users, but they eventually run across the steeper part when they want to adjust their workflow (i.e., they will eventually learn about non-symmetric repo topologies because those are part of many useful workflows). But I think it's a good thing to push that part of the learning curve out, because: 1. Some people may stay in the centralized view their whole lives and never care. 2. It will make more sense to them, because they'll understand how it fits into what they're trying to do, rather than viewing it as an arcane and senseless default. There may be some confusion as people hit that learning point. I won't be surprised if we end up adding more advice.* messages in certain cases to guide people to adjusting their push.default. But I'm just as happy to wait until people start hitting the confusion point in practice, and we can see more clearly when that advice should trigger, and what it should say. Oh, I agree with you that adding new support for triangular workflow will not hurt the centralized folks. I was more interested about helping the fetch from here, push to there people. In Git, there will always be a combination of switches which allows you to go the centralized workflow mode. We're focusing on expanding this list of switches, to free up distributed workflows into more possibilities. We're currently targeting problems that affect us everyday; the ones we've failed to notice. Centralized people do not have to configure anything for each branch for git push to push their current branch to where they fetch from and to the same name (you start building on their 'master', your result go to their 'master', because as a centralized person, you are part of 'them'). They have branch.$name.merge that names what their $name branch merges with, and that is sufficient to decide to which branch the result is to be pushed back. What about the branch.$name.pushRef, which was proposed earlier? They should be able to say, at a per-branch level, which branches to send for review (in Gerrit). With the push.defaultTo = peff to name what remote the git push will push to, or even with the branch.master.remotepush = peff to decide that per branch, would fetch from here, push to there people have a way similar to what branch.$name.merge gives to the centralized people to decide what branch is updated? Ah. It almost seems to me that we may want to extend the semantics given to the remote.$name.push refspecs. They are primarily for perfect all branches you are going to push out, and push them in one go with 'git push' workflow, but if it is clear that you are not following that (e.g. you are doing an equivalent of what the centralized folks would do with push.default = simple/upstream/current) and pushing only the current branch, perhaps we should look at these refspecs to see where the current branch goes? I'd actually just go with the current syntax + per-branch overrides. Simple and serves the purpose: I don't think there'll be real usecases outside this. In your case, 'refs/heads/master' would likely to go to 'refs/heads/master', and we could treat a missing remote.peff.push an equivalent to having remote.peff.push = refs/heads/*:refs/heads/* I'll get to work on a patch that deems the configuration variable as not necessary. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Junio C Hamano wrote: [remote origin] url = ... where Ram fetches and pulls from ... pushurl = ... where Ram pushes to ... fetch = refs/heads/*:refs/remotes/* updateTrackOnPush = no Then git fetch (or git pull) will update the remote tracking branches Ram fetches from, and once his topic is finished, he can push to his publishing location, which won't touch the remote tracking branches used to keep track of the place he fetches from. A push should never touch remote/refs/origin/* if there is a pushurl configured. Otherwise, it should. I want my push to affect my status. The configuration variable makes no sense and should not exist. Unfortunately, pushurl doesn't get the same privileges as url even though they're equal remotes. How is my fork inferior to the upstream project in any way? A lot of us might be working on this fork, and we will need something corresponding to refs/remotes/* to inspect its state. Like I said earlier, I think pushurl has a very limited usecase: when the two URLs are actually mirrors (there is really no fork; we're back in a centralized environment). In fact, I think it should be deprecated, because it interferes with my more general approach. Let's see what happens if we have two actual remotes. remote/refs/origin/* will be updated when I fetch from, and push to, origin. remote/refs/ram/* will be updated when I fetch from, and push to, ram. It's very simple, and I don't need this complex rule of when to update refs. We should have a way to pair remotes together as upstream/ downstream in the future. Maybe even have a hierarchy of remotes. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Michael J Gruber wrote: Junio C Hamano venit, vidit, dixit 08.02.2013 09:16: Jonathan Nieder jrnie...@gmail.com writes: Wait, why did the remote rewind? Oh, I am very well aware of that glitch. git push has this hack to pretend as if the pusher immediately turned around and fetched from the remote. It shouldn't have been made to do so unconditionally; instead it should have been designed to give the pushee a way to optionally tell you I acccept this push, but you may not see it to be updated to that exact value you pushed when you fetched from me right now. Yes, I agree with this. The git push hack does seem to be useful in practice for helping people just starting to use git. If they have a separate gitk --all window open, they can refresh it and see the remote-tracking branch corresponding to the branch that has been pushed advancing. It matches a model in which remote-tracking refs represent git's idea of where these branches are in the remote repository. And in that model, a remote being able to respond to a push with ref update queued, but please keep in mind that it may take me a while to chew through that queue should be perfectly reasonable. [...] And this seems to be more natural, too. It can keep the internals (the auxiliary ref on the server side) hidden from the user. Just to clarify: this is not an internal ref being exposed. No auxiliary refs/for/master ref actually exists. The ref Gerrit users push to is a UI fiction. That's important because otherwise two developers could not propose changes for the same branch at the same time. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Jonathan Nieder wrote: Ramkumar Ramachandra wrote: And yes, a regular `git push origin refs/for/master` is just retarded. The usual incantation is git push gerrit HEAD:refs/for/master. Is the code review creation push that uses a different branchname from the branch the integrator pulls what seems backward, or is it the need to specify a refname at all on the command line? How else would you design a system to differentiate between a push-for-review, and push-to-update-ref? On a slightly unrelated note, it would be nice if we could streamline the git-format-patch, git-send-email process. Let's say we make it a push', which has a pre-hook that fires up the $EDITOR for a cover letter. Wouldn't you love it if this push' would update refs on your private fork and fire off emails to the Git List? Bonus for contrib/: fetch the Google address book, and allow me to auto-complete names when sending emails. I agree that a [branch master] pushremote configuration would be handy. pushremote instead of remotepush to be less surprising to people who have already seen pushurl. Thanks for that, by the way (used in RFC patch). My taste in variable names is a little sour. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: [remote origin] url = ... where Ram fetches and pulls from ... pushurl = ... where Ram pushes to ... fetch = refs/heads/*:refs/remotes/* updateTrackOnPush = no Then git fetch (or git pull) will update the remote tracking branches Ram fetches from, and once his topic is finished, he can push to his publishing location, which won't touch the remote tracking branches used to keep track of the place he fetches from. A push should never touch remote/refs/origin/* if there is a pushurl configured. Otherwise, it should. That is a horrible design, no? Because one of the main use case for pushurl is to use url = git:// for less overhead and pushurl = ssh+git:// for authentication but otherwise going to the same place. So if git push is allowed to pretend you immediately turned around and fetched, push to that pushurl will pretend it was followed by a fetch from the corresponding url. You need a way to tell if the pushurl/url pair is used for that purpose to let Git know if that is the case. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
On 02/07/2013 05:14 PM, Ramkumar Ramachandra wrote: This has been annoying me for a really long time, but I never really got around to scratching this particular itch. I have a very common scenario where I fork a project on GitHub. I have two configured remotes: origin which points to git://upstream and mine which points to ssh://mine. By default, I always want to pull `master` from origin and push to mine. Unfortunately, there's only a branch.name.remote which specifies which remote to use for both pulling and pushing. There's also a remote.name.pushurl, but I get the feeling that this exists for an entirely different reason: when I have a server with a highly-available read-only mirror of the repository at git://anongit.*, and a less-available committer-only mirror at ssh://*. How about a branch.name.remotepush that specifies a special remote for pushing, falling back to branch.name.remote? Additionally, it would be nice to have branch.name.push or similar to configure a default destination branch for push. Gerrit users usually want to track refs/heads/master but push to refs/for/master for example. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Ramkumar Ramachandra wrote: Ramkumar Ramachandra wrote: And yes, a regular `git push origin refs/for/master` is just retarded. Actually a git config remote.origin.push refs/heads/*:refs/for/* makes more sense here. Sorry about all that confusion. The first line should be `git push origin master:refs/for/master`, but a rule like refs/head/*:refs/for/* is insufficient: what if I want refs/head/*:refs/heads/* for one set of branches (private ones that I don't send for review), and refs/heads/*:refs/for/* for another set (which I send for review)? That certainly won't play well will the existing remote.origin.push; it'd have to behave as an override. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Hi Ram, Ramkumar Ramachandra wrote: And yes, a regular `git push origin refs/for/master` is just retarded. The usual incantation is git push gerrit HEAD:refs/for/master. Is the code review creation push that uses a different branchname from the branch the integrator pulls what seems backward, or is it the need to specify a refname at all on the command line? I agree that a [branch master] pushremote configuration would be handy. pushremote instead of remotepush to be less surprising to people who have already seen pushurl. Good luck, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Jonathan Nieder jrnie...@gmail.com writes: The usual incantation is git push gerrit HEAD:refs/for/master. Is the code review creation push that uses a different branchname from the branch the integrator pulls what seems backward, or is it the need to specify a refname at all on the command line? I agree that a [branch master] pushremote configuration would be handy. pushremote instead of remotepush to be less surprising to people who have already seen pushurl. I'd actually see this as Gerrit being weird. If it wants to quarantine a commit destined to the master branch, couldn't it just let people push to master and then internally update for/master instead? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote: This has been annoying me for a really long time, but I never really got around to scratching this particular itch. I have a very common scenario where I fork a project on GitHub. I have two configured remotes: origin which points to git://upstream and mine which points to ssh://mine. By default, I always want to pull `master` from origin and push to mine. Same here. Even without GitHub, working on git.git I treat Junio as my origin, but push to a publishing point. Unfortunately, there's only a branch.name.remote which specifies which remote to use for both pulling and pushing. There's also a remote.name.pushurl, but I get the feeling that this exists for an entirely different reason: when I have a server with a highly-available read-only mirror of the repository at git://anongit.*, and a less-available committer-only mirror at ssh://*. Yeah, you don't want to use pushurl. It makes the assumption that you are pushing to the same remote, so when you, e.g., push to the remote's refs/heads/master, it will update refs/remotes/origin/master. But that's not right; that ref should be tracking the true origin, not what you pushed to. How about a branch.name.remotepush that specifies a special remote for pushing, falling back to branch.name.remote? Sure, though I wonder if you really want a per-branch config, or if you just want remote.pushDefault or similar, so that you do not have to configure each branch independently as you create it. I'm imagining lookup rules something like: 1. If we are on branch $b, check branch.$b.pushRemote. 2. If not set, check remote.pushDefault. 3. If not set, check branch.$b.remote. 4. If not set, check remote.default (there was a proposal for this a few months ago, but it got stalled). 5. If not set, use origin. And then fetching could do the same, with s/push/fetch/. In both cases, if you are not using the new variables, the behavior is the same as the current behavior. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Jeff King p...@peff.net writes: On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote: This has been annoying me for a really long time, but I never really got around to scratching this particular itch. I have a very common scenario where I fork a project on GitHub. I have two configured remotes: origin which points to git://upstream and mine which points to ssh://mine. By default, I always want to pull `master` from origin and push to mine. Same here. Even without GitHub, working on git.git I treat Junio as my origin, but push to a publishing point. The you fetch from and push to the same place semantics that associates a branch to a single remote was primarily done for people coming from CVS/SVN background [*1*]. I think the triangle arrangement where you want to have this is where I fetch from and integrate with, and that is where I publish is more common among the Git users these days. How best to express the triangle is somewhat tricky, but I think it is sensible to say you have origin that points to your upstream (i.e. me), and peff that points to your publishing point, in other words, make it explicit that the user deals with two remotes. Then have push.default name the remote peff, so that git push goes to that remote by default (and have git fetch/pull go to origin). You will have two sets of remote tracking branches (one from origin that your push will never pretend to have fetched immediately after finishing, the other from peff that keeps track of what you pushed the last time). Of course, some people may have I use this and that branches to interact with upstream X while I use these other branches to interacct with upstream Y, and all of them push to different places, and supporting that may need complex per branch On this branch fetch from and integrate with remote X, and push to remote Z settings, but as you said, I fetch from and integrate with X, and result is pushed out to Y should be the most common, and it would be desirable to have a simple way to express it with just a single new configuration variable. [Footnote] *1* It also happens to work reasonably well for people like Linus and I with the I pull from random places, I locally integrate and I publish the results workflow, because we are trained to think that it is not just being lazy but simply meaningless to say git pull without saying fetch and integrate _what_ and from _whom_, and that is only because we do not have a fixed upstream. Linus and I would practically never fetch from origin, i.e. from ourselves. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote: How best to express the triangle is somewhat tricky, but I think it is sensible to say you have origin that points to your upstream (i.e. me), and peff that points to your publishing point, in other words, make it explicit that the user deals with two remotes. Then have push.default name the remote peff, so that git push goes to that remote by default (and have git fetch/pull go to origin). You will have two sets of remote tracking branches (one from origin that your push will never pretend to have fetched immediately after finishing, the other from peff that keeps track of what you pushed the last time). Exactly. That is what I have set up now, except that I have to type git push peff because there is no such push.default (with the minor nit that push.default does something else, so the config should be called remote.pushDefault or something). The entirety of the feature would be saving the user from the annoyance of: $ git push fatal: remote error: You can't push to git://github.com/gitster/git.git Use g...@github.com:gitster/git.git [doh! Stupid git, why don't you do what I mean, not what I say?] $ git push peff ... it works ... Of course, some people may have I use this and that branches to interact with upstream X while I use these other branches to interacct with upstream Y, and all of them push to different places, and supporting that may need complex per branch On this branch fetch from and integrate with remote X, and push to remote Z settings, but as you said, I fetch from and integrate with X, and result is pushed out to Y should be the most common, and it would be desirable to have a simple way to express it with just a single new configuration variable. Right. Frankly, I do not care that much about the per-branch push remote myself. In the rules I gave earlier, that was my complete backwards-compatible vision, so that we do not paint ourselves into a corner compatibility-wise when somebody wants it later. Just implementing the default push remote part would be a fine first step. I also indicated in my rules that we could have a branch.*.fetchRemote, as well, but I do not think it is strictly necessary. I think the non-specific branch.*.remote could continue to be used for fetching, and as a backup when the push-specific variables are not set. *1* It also happens to work reasonably well for people like Linus and I with the I pull from random places, I locally integrate and I publish the results workflow, because we are trained to think that it is not just being lazy but simply meaningless to say git pull without saying fetch and integrate _what_ and from _whom_, and that is only because we do not have a fixed upstream. Linus and I would practically never fetch from origin, i.e. from ourselves. Right, I think git pull is more useful in a centralized repo setting where there is one branch and one repo, so there is no what and whom to specify. Personally I do not use it much at all, as I do a separate fetch, inspect, and merge, but that is somewhat orthogonal to your reasons. :) -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Junio C Hamano gits...@pobox.com writes:
I think the triangle
arrangement where you want to have this is where I fetch from and
integrate with, and that is where I publish is more common among
the Git users these days.
Another thing to know about is that the recent move to change the
behaviour of git push to work only on one branch per default may
have to be polished and strengthened a bit.
Originally, the encouraged workflow was to perfect _everything_ that
you would push out and then with a single git push to publish
everything at the same time. Both the matching behaviour of git
push which was the default, and the set of push refspecs that is to
be defined per remote, were ways to discourage Work on one branch,
think it is OK, hastily push only that branch out, switch to another
branch, rinse, repeat.
To support a triangular arrangement well, there may need some
thinking on what $branch@{upstream} means. The original intent of
the upstream mode specified for push.default is push the result
back to what you based your work on, but in a triangular arrangement
that is no longer true. You may be keeping up with my 'master' by
constantly rebasing and then pushing out the result to your 'frotz'
topic. You want to have a lazy git fetch to fetch from my
'master' (i.e. upstream), and have remotes/origin/master to keep
track of it. You want to see git rebase to pay attention to the
updates to remotes/origin/master when figuring out where you forked.
But at the same time, you want a lazy git push to go to your
push.defaultTo repository (i.e. your publish point) and update your
'frotz' branch there---remotes/origin/master should not come into
the picture at all. But the upstream and simple modes want to pay
attention to branch.$name.merge, which is all about the fetch and
integrate side of the equation.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: branch.name.remotepush
Junio C Hamano wrote: I'd actually see this as Gerrit being weird. If it wants to quarantine a commit destined to the master branch, couldn't it just let people push to master and then internally update for/master instead? It is because pushing doesn't update refs/heads/master. Instead, it starts a code review. Suppose Gerrit allows starting a new code review by pushing to refs/heads/master. It sounds okay if I squint --- it's just a very slow asynchronous ref update, right? Let's see: $ git clone gerrit server test Cloning into 'test'... $ echo hi greeting $ git add greeting $ git commit -q -m 'hello' $ git push origin master [...] remote: New Changes: remote: gerrit server/r/1234 remote: To url ea4cb77b..9117390e master - master $ : walk away, forget what I was doing $ git fetch origin From url + 9117390...ea4cb77 master - origin/master (forced update) Wait, why did the remote rewind? Regards, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal for git stash rename
On 01/04/2013 10:40 PM, Junio C Hamano wrote: Micheil Smith mich...@brandedcode.com writes: This patch implements a git stash rename using a new git reflog update command that updates the message associated with a reflog entry. ... I note that this proposal is now two years old. A work in progress patch was requested, however, after one was given this thread ended. I'm also finding a need for this feature; The whole point of reflog is that it is a mechanism to let users to go safely back to the previous state, by using a file that is pretty much append-only. It feels that a mechanism to rewrite one goes completely against that principle, at least to me. The implementation of git stash itself seems to violate your principle, by storing its branches-that-are-not-branches within a mutable reflog. Just an observation... Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal for git stash rename
Greg Hewgill greg at hewgill.com writes: On Sun, Jun 20, 2010 at 10:54:43AM +, ??var Arnfj??r?? Bjarmason wrote: It's good to post a WIP PATCH even if it needs cleanup, just as a point for further discussion. Thanks, point taken. WIP patch follows. This patch implements a git stash rename using a new git reflog update command that updates the message associated with a reflog entry. --- [--snip--] Hi, I note that this proposal is now two years old. A work in progress patch was requested, however, after one was given this thread ended. I'm also finding a need for this feature; Not to try and bump an old thread, but what's the best way to land this? – Micheil Smith @miksago -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal for git stash rename
Micheil Smith mich...@brandedcode.com writes: This patch implements a git stash rename using a new git reflog update command that updates the message associated with a reflog entry. ... I note that this proposal is now two years old. A work in progress patch was requested, however, after one was given this thread ended. I'm also finding a need for this feature; The whole point of reflog is that it is a mechanism to let users to go safely back to the previous state, by using a file that is pretty much append-only. It feels that a mechanism to rewrite one goes completely against that principle, at least to me. I have a feeling that need in need for this feature is a misspelt want, that occasional misspelling of the stash message may give users awkward feelings when viewing git stash list output but not severe enough to make them unable to identify which stash entry holds which change, and that it is sufficient to pop and then restash if a user *really* cares. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
Martin von Zweigbergk martinv...@gmail.com writes: On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset originally wanted to. I do use commit --amend a lot, but I still appreciate having reset --soft. For example, to squash the last few commits: git reset --soft HEAD^^^ git commit --amend Yeah, I do that sometimes myself, but the key word is sometimes. These days, I think most users (not just mortals but experienced ones) use rebase -i to squash them altogether, either with fixup, with which you lose the messages from the follow-up fixes, just like the soft reset to an old one with an amen,) or with squash, with which you can pick pieces of messages from the follow-up fixes while updating the message from the original one. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Mon, Dec 17, 2012 at 10:34:07PM -0800, Martin von Zweigbergk wrote: On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset originally wanted to. I do use commit --amend a lot, but I still appreciate having reset --soft. For example, to squash the last few commits: git reset --soft HEAD^^^ git commit --amend Me too. Another one I use is: $ hack hack hack $ git commit -m wip $ git checkout something-else ... time passes ... $ git checkout orig-branch $ git reset --soft HEAD^ $ hack hack hack $ git diff $ git add -p $ git commit which ends up with the same history as commit --amend, but in between the reset and the commit, the bogus WIP commit is thrown away entirely. And things like diff and add -p do what you want, instead of showing your progress on top of the WIP. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Wed, Nov 23, 2011 at 12:49 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Philippe Vaucher philippe.vauc...@gmail.com writes: Optional: a new mode would be introduced for consistency: --worktree (or maybe --tree): only updates the worktree but not the index That would be an alias for git checkout rev -- path, right? Not quite, in two ways, I think. First, it _would_ update the index, wouldn't it? Second, git checkout rev -- path doesn't delete files that are deleted in rev as compared to head. I'm considering implementing support for an operation that would do what I expected git checkout rev -- path and git reset --hard rev -- path to do. I'm currently planning for it to be exactly git reset --hard rev -- path (which is currently simply not allowed), but perhaps it would be more natural as an option to checkout (--also-deleted or something)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote:
I am guilty of introducing git reset --soft HEAD^ before I invented
commit --amend during v1.3.0 timeframe to solve the issue soft reset
originally wanted to.
I do use commit --amend a lot, but I still appreciate having reset
--soft. For example, to squash the last few commits:
git reset --soft HEAD^^^ git commit --amend
or undo commit --amend:
git reset --soft HEAD@{1} git commit --amend
Maybe there's a better way of doing that?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Wednesday 2012-10-03 21:03, Junio C Hamano wrote: I said that git reset --keep started out as an ugly workaround for the lack of git checkout -B $current_branch. Now we have it, so we can afford to make reset --keep less prominently advertised in our tool set. As I already said back then, reset --soft also has outlived its usefulness when commit --amend came, so that leaves only these modes of reset: Soft is still useful, partway. Consider patch splitting (where easily possible): $ git add foo.c bar.c $ git commit -m foo,bar [other commits] $ git rebase -i FOOBARCOMMIT^ [mark foo,bar for edit] $ git reset --soft HEAD^ $ git reset bar.c $ git commit -m foo $ git add bar.c $ git commit -m bar $ git rebase --continue -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
Phil Hord phil.h...@gmail.com writes: I flagged this for followup in my MUA, but I failed to follow-up after the holidays. I apologize for that, and I really regret it because I liked where this was going. I really regret to see you remembered it, actually. 1) Newbie user clones/pulls a repository from somewhere. He hacks around and then things go bad, and he decides to scratch away everything he did to make sure things are like they're supposed to be. He'd then type git checkout --force --clean master. If he didn't introduce new files, he would simply type git checkout --force master I like this just fine. I think we can explicitly say that HEAD is the implied default refspec, yes? git checkout --force --clean That depends on what the hacks around involved. Where is he now, what damage did he cause, and what can you depend on to take him to a clean state, where the definition of clean happens to match this hypothetical Newbie user? Did he do git checkout of another branch? Did he commit? Did he reset to other commit while on the 'master' branch? Is he still on master branch when he says git checkout --force --clean master? Can he say git checkout --force --clean master~4 and what does that even mean? Is he trying to go into the detached HEAD state, or is he somehow trying to rewind master? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
Junio C Hamano gits...@pobox.com writes: Phil Hord phil.h...@gmail.com writes: I flagged this for followup in my MUA, but I failed to follow-up after the holidays. I apologize for that, and I really regret it because I liked where this was going. I really regret to see you remembered it, actually. Having said that, I am glad that you brought the old discussion thread to our attention. In http://thread.gmane.org/gmane.comp.version-control.git/185825/focus=185863, I said that git reset --keep started out as an ugly workaround for the lack of git checkout -B $current_branch. Now we have it, so we can afford to make reset --keep less prominently advertised in our tool set. As I already said back then, reset --soft also has outlived its usefulness when commit --amend came, so that leaves only these modes of reset: reset --hard [$commit] reset [$commit] reset --merge I am not sure if it makes sense to give a commit different from HEAD to reset --merge, and to a lessor degree, reset --mixed to flip the HEAD to another commit while retaining the working tree contents does not make much sense, either, in a common workflow. It _might_ be possible to merge the --mixed and --merge if we think things through to reduce the often-used options even further, but I haven't done so, and I suspect nobody has (yet). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: a small git proposal
Thanks for the tip. It should give me a good starting point for what I'm about to do, since notes seem to be able to add comments for objects without changing the commit tree (which was one of the things I was aiming for and quite frankly, one of the parts that worried me on the implementation side). However, what I want to implement has a few differences: a) the flags I'm proposing form a limited set of strings, as I'm interested in finding which files have a particular flag (I did mention the idea to add comment as well when adding a certain flag, but that was something extra, since most of the searching/listing was around the set of flags of a certain file, not around the comment itself... I can cook up some more usage and output examples if anyone thinks it can clear things up). I realize this can be achieved by using a sound naming convention (and a simple grep for a particular prefix when listing all notes would handle the search by flag I mentioned) - unfortunately, some other differences don't seem to be covered as you'll see below b) I would like to have all subsequent versions of a file to inherit the flags/tags of the original file, until specified otherwise; in the original idea that a 'feature tag' (or 'flag' as I keep calling them lately - seems a better name that 'feature tag') remains on the file until someone decides that feature is no longer implemented in the file (for example, a file implements a certain technique since version 3 until version 15, when the implementation of a particular method changed entirely). Unfortunately, what seems to be a good choice to preserve a state of a file until not needed are branches, but then I would need to have the same version of the file on different branches (a file can have multiple flags after all, since multiple features are usually implemented in a file) Anyway, I just wanted to point out that the notes you suggested are not quite what I was looking for, but it should be a good implementation starting point, so again, lots of thanks. Catalin Pol On Thu, Aug 23, 2012 at 6:16 PM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: On 23 August 2012 08:10, Catalin Pol catalin@gmail.com wrote: Hi everyone, This is my first email to this mailing list, so this may be somehow too straight forward... the idea is that I was thinking to develop a new feature in Git (although I'm kind of new to git myself). I wrote a small description of what I intend to do and I figured I could use some pointers (how I can improve it, any possible usage scenarios you can think for it and so on). Details are available at the gist link below or as attachment to this email (I zipped the text file since it was more it is larger than 10k and I didn't want it to get rejected by the email server... although it still might) gist link:https://gist.github.com/3437530 I made the gist public, so feel free to edit it directly... or, if you prefer, just email me with any comments. I'm opened to any suggestion, so feel free to send me any kind of comment (maybe I'm trying to implement something that is already in git for example, and since I'm a bit of a newbie in the git world, I didn't notice any way to obtain my desired workflow). Thanks in advance for any feedback, Have you looked at git notes? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: a small git proposal
On 23 August 2012 08:10, Catalin Pol catalin@gmail.com wrote: Hi everyone, This is my first email to this mailing list, so this may be somehow too straight forward... the idea is that I was thinking to develop a new feature in Git (although I'm kind of new to git myself). I wrote a small description of what I intend to do and I figured I could use some pointers (how I can improve it, any possible usage scenarios you can think for it and so on). Details are available at the gist link below or as attachment to this email (I zipped the text file since it was more it is larger than 10k and I didn't want it to get rejected by the email server... although it still might) gist link:https://gist.github.com/3437530 I made the gist public, so feel free to edit it directly... or, if you prefer, just email me with any comments. I'm opened to any suggestion, so feel free to send me any kind of comment (maybe I'm trying to implement something that is already in git for example, and since I'm a bit of a newbie in the git world, I didn't notice any way to obtain my desired workflow). Thanks in advance for any feedback, Have you looked at git notes? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enhanced git branch list (proposal)
On Mon, Jul 23, 2012 at 2:17 PM, John Bartholomew
jpa.bartholo...@gmail.com wrote:
I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream. For some time I have been using my
own script to do this. It produces output like this:
$ git lsb
commodity-market-lua [behind 'brianetta/commodity-market-lua' by 2
commits]
filesystem [up-to-date with 'jpab/filesystem']
fix-ring-blending [ahead of 'jpab/fix-ring-blending' by 1 commit]
galaxy-refactor
galaxy-refactor-2 [diverged from 'jpab/galaxy-refactor', by 6
commits/626 commits (us/them)]
hud-pitch-ladder [up-to-date with 'jpab/hud-pitch-ladder']
= issue-1388
issue-695
lmr-mtllib-improvements
marcel-stations
* master [up-to-date with 'jpab/master']
refcounted-body [up-to-date with 'jpab/refcounted-body']
string-formatter [up-to-date with 'jpab/string-formatter']
The first column indicates the relation to HEAD: '*' marks the current
head, '=' marks a branch which is identical with the current HEAD.
Branches which have a configured upstream (branch.remote and
branch.merge are set) show the relation to the corresponding remote
branch.
Some key text ('up-to-date', 'ahead', 'behind' or 'diverged', and the
name of the current HEAD) is displayed with colour if colour is
enabled.
Arguments can be passed to show remote branches (for all remotes, or
for a specified remote), or all branches, and to show each branch
in relation to a specified target branch instead of the configured
remote tracking branch.
I would like to know whether there is any interest in incorporating
this functionality into the main git distribution, either as a
separate command, or within `git branch'. For my purposes I have it
aliased under the name `git lsb' for `list branches'.
You can examine the script I'm using for this at:
https://github.com/johnbartholomew/gitvoodoo/blob/master/bin/git-xbranch
Thanks. You might also find this one interesting:
http://masanjin.net/blog/label/git-wtf/
Phil
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Enhanced git branch list (proposal)
I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream. For some time I have been using my
own script to do this. It produces output like this:
$ git lsb
commodity-market-lua [behind 'brianetta/commodity-market-lua' by 2
commits]
filesystem [up-to-date with 'jpab/filesystem']
fix-ring-blending [ahead of 'jpab/fix-ring-blending' by 1 commit]
galaxy-refactor
galaxy-refactor-2 [diverged from 'jpab/galaxy-refactor', by 6
commits/626 commits (us/them)]
hud-pitch-ladder [up-to-date with 'jpab/hud-pitch-ladder']
= issue-1388
issue-695
lmr-mtllib-improvements
marcel-stations
* master [up-to-date with 'jpab/master']
refcounted-body [up-to-date with 'jpab/refcounted-body']
string-formatter [up-to-date with 'jpab/string-formatter']
The first column indicates the relation to HEAD: '*' marks the current
head, '=' marks a branch which is identical with the current HEAD.
Branches which have a configured upstream (branch.remote and
branch.merge are set) show the relation to the corresponding remote
branch.
Some key text ('up-to-date', 'ahead', 'behind' or 'diverged', and the
name of the current HEAD) is displayed with colour if colour is
enabled.
Arguments can be passed to show remote branches (for all remotes, or
for a specified remote), or all branches, and to show each branch
in relation to a specified target branch instead of the configured
remote tracking branch.
I would like to know whether there is any interest in incorporating
this functionality into the main git distribution, either as a
separate command, or within `git branch'. For my purposes I have it
aliased under the name `git lsb' for `list branches'.
You can examine the script I'm using for this at:
https://github.com/johnbartholomew/gitvoodoo/blob/master/bin/git-xbranch
Regards,
John B
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enhanced git branch list (proposal)
John Bartholomew jpa.bartholo...@gmail.com writes:
I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream.
That is already present: just run git branch -vv.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
proposal: delta based git archival
I noticed people on this mailing list start talking about using blob deltas for compression, and the basic issue that the resulting files are too small for efficient filesystem storage. I thought about this a little and decided I should send out my ideas for discussion. In my proposal, the current git object storage model (one compressed object per file) remains as the primary storage mechanism, however there would be some kind of backup mechanism based on multiple deltas grouped in one file. For example, suppose you're looking for an object with a hash of eab75ce51622aa312bb0b03572d43769f420c347 First you'd look at .git/objects/ea/b75ce51622aa312bb0b03572d43769f420c347 - if the file exists, that's your object. If the file does not exist, you'd then look for .git/deltas/ea/b, .git/deltas/ea/b7, .git/deltas/ea/b75, .git/deltas/ea/b75c, ... up to some maximum search path lenght. You stop at the first file you can find. Supposing that file is .git/deltas/ea/b7, it would contain a diff (let's assume unified format for now, though ideally it'd be better to have something that allows binary file deltas too) of many archived objects with hashes starting with eab7, compared to a different object (presumably some direct or indirect ancestor): diff -u 8f5ba0203e31204c5c052d995a5b4449226bcfb5 eab75ce51622aa312bb0b03572d43769f420c347 --- 8f5ba0203e31204c5c052d995a5b4449226bcfb5 +++ eab75ce51622aa312bb0b03572d43769f420c347 @@ -522,7 +522,7 @@ diff -u 77dc2cb94930017f62b55b9706cbadda8c90f650 eab71c51dbc62797d6c903203de44cc6a734c05c --- 77dc2cb94930017f62b55b9706cbadda8c90f650 +++ eab71c51dbc62797d6c903203de44cc6a734c05c @@ -560,13 +563,17 @@ ... Based on this delta file, we'd then look for the object 8f5ba0203e31204c5c052d995a5b4449226bcfb5 (this process could require recursively rebuilding that object) and try to build eab75ce51622aa312bb0b03572d43769f420c347 by applying the delta and then double checking the hash. To me the strenghts of this proposal would be: * It does not muddy the git object model - it just acts independently of it, as a way to rebuild git objects from deltas * Old objects can be compressed by creating a delta with a close ancestor, then erasing the original file storage for that object. The object delta can be appended to an existing delta file (which avoids the small-file storage issue), or if the delta file gets too big, it can be split off into 16 smaller files based on the hashes of the objects this file stores deltas for. * The system is flexible enough to explore different delta strategies. For example one could decide to keep one object every 10 in the database and store other 9 as deltas based on the immediate object ancestor, or any other tradeoff - and the system would still work the same (with different performance tradeoffs though). Does this sound insane ? Too complicated maybe ? Is there any kind of semi-standard binary-capable multiple-file diff format that could be used for this application instead of unified diffs ? -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal: delta based git archival
On 4/22/05, Michel Lespinasse [EMAIL PROTECTED] wrote: I noticed people on this mailing list start talking about using blob deltas for compression, and the basic issue that the resulting files are too small for efficient filesystem storage. I thought about this a little and decided I should send out my ideas for discussion. I've been thinking in another simpler approach. The main benefit of using deltas is reducing the bandwith use in pull/push. My idea is leaving the blob storage as it is by now and adding a new kind of object (remote) that acts as a link to an object in another repository. So that, when you rsync, you don't have to get all the blobs (which can be a lot of data), but only the sha1 of the new objects created. Then a remote object is created for each new object in the local repository pointing to its location in the external repository. Once the rsync is done, when git has to access any of the new objects they can be fetched from the original location, so that only necessary objects are transfered. This way, the cost of a sync in terms of bandwith is nearly zero. I've been working on this, so if you think it to be a good idea, I can send a patch when I get it fully working. Regards, Jaime Medrano. http://jmedrano.sl-form.com - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Proposal for simplification and impovement of the git model
In this message, a method to simplify and at the same time make more
powerful the git abstraction is presented.
I believe that the enhancements I propose make git adhere even more to
its spirit and make it more intuitive.
The proposal makes it much easier to build an SCM over git, obtaining in
particular the following advantages:
- Blob and tree objects become symmetric
- Commit objects are removed (their data is put inside tree objects)
- Commit comments are per-file
- A tree in a repository looks like a repository itself, with full
version information (now only the one mentioned in the commit object has
version information)
- File and directory renames are tracked
- Renames are tracked regardless of the way they are made (even with cp
and rm)
- Commit comments can be updated at any time by whoever made the change
- Doing the blame operation is trivial
- Minimizing disk space usage (at the expense of speed) by storing diffs
is easily doable
The basic idea is that rather than having single blob or tree revisions
as the base concept, the abstract base unit is the whole set of
modifications, with comments, leading to that state.
Of course, tracking that would be extremely space-inefficient, so we
instead track the current file contents, plus the public key of the
author and the hashes of all parents.
This is implemented with the following changes to git:
- The commit object is removed
- Each tree must have a .git-commit file that contains the information
previously in the commit object (only for immediate children, thus
having a .git-commit file in each directory), but with the author
public key instead of the comments
- Each blob will be hashed as the blob contents plus an header in a
canonical format that contains data similar to the data in the
.git-commit file
- When checked out, the blob header is put in a C/C++ comment, a #
comment, or if the file format is unknown, in an extended attribute or a
separate file
An example of a C/C++ file with metadata is the following:
// @parentSHA1_OF_PARENT1 @parentSHA1_OF_PARENT2
// @authorFINGERPRINT_OF_AUTHOR_PUBLIC_KEY
#include stdlib.h
int main(int argc, char** argv)
{
printf(Hello, world!\n);
return 0;
}
Note that @parent and @author in checked out files are NOT the same
of the ones in the repository but are crafted so that there is a single
@parent pointing to the repository file and @author is taken from
$HOME/.gitrc
- When the file is checked in, the header is parsed and removed.
* If there is a single parent, its header is added and the resulting
buffer is hashed and compared with the parent's hash. If equal, the file
is unchanged and not committed.
* Otherwise, the header data is added in a canonical format and the
buffer is hashed and committed
- A new class of objects is added, that is not named by their hash, but
rather by a public key (or fingerprint of it), a timestamp and a name.
The object is correct if and only if the contents plus name and
timestamp are signed with the private key corresponding to public key in
the name.
Object names are formatted as id/name/args where url is an
uuid or url that makes the id/name unique, name is the name, and
args is additional data.
File names formatted like git/c/sha1 are interpreted as commit
comments for object sha1.
- For storage or network transmission purposes, a binary diff against
the parents can be stored instead of the contents af an object. This
will of course require to walk the whole history to rebuild it, but
smarter schemes are possible (e.g. keyframes, jump diffs, etc.).
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
